git-sync: need to define behavior

[charlierudolph]

Here is the test case:

  Background:
    Given I am on the "feature" branch
    And the following commits exist in my repository
      | BRANCH  | LOCATION | MESSAGE                   | FILE NAME        | FILE CONTENT               |
      | main    | remote   | remote main commit        | main_file        | main content               |
      | feature | remote   | remote conflicting commit | conflicting_file | remote conflicting content |
      | feature | local    | local conflicting commit  | conflicting_file | local conflicting content  |
    And I run `git sync` while allowing errors

This will run and I will end up with conflicts when merging the tracking branch.
If I abort the command, I am left with the feature branch being ahead of its remote branch (because it has the changes from the main branch brought in).

I think we either need to

• push the branch when aborting to bring to branch in sync with its remote
  or
• reset the branch to its SHA before the merge with main.

[kevgo]

I would say it works as intended. "abort" is supposed to get me out of the current mess, and back into a consistent state. The scenario you describe is consistent, although I agree not very nice. The better thing to do in this situation is "undo", which would do what you describe (reset the local branch back to its state before merging), or "continue", which would do the push and finish the sync.

The first alternative (pushing to remote when aborting) seems counterintuitive to me, I wouldn't want to do it.

This makes me think whether "abort" is something we want to support at all. I think "undo" and "continue" are better in most situations.

[charlierudolph]

To me you undo something that successfully completed, and abort something that you are in the middle of. Yes we are "undoing" some git commands, but at a high level we are "aborting" the git-sync.

I agree pushing when aborting is weird, I think abort should reset the branch to how it then.

[kevgo]

To make "abort" consistent with how it works on Git, we could change it so that it tries to undo the currently running command as much as possible. I could see value in that, and even that this is better than the current behavior of leaving the user somewhere in the middle. The new command pattern implementation with undo list would make this trivial as well.