Re: git merge --abort

John Tapsell [off-list ref] writes:

2009/2/19 Jay Soffian [off-list ref]:

quoted

On Thu, Feb 19, 2009 at 8:34 AM, John Tapsell [off-list ref] wrote:

quoted

There's no reliable way of getting back to the state before the merge?

Sure there is. Commit or stash before you merge, so that your index
and working copy are clean.

Could a stash be done automatically by the merge command, for just a case?

It cuts both ways.  For people who work on a well organized project
(i.e. highly modularized) and tend to keep local changes in the work tree
while doing a lot of merges, running "stash" every time would (1) remove
the local change from the work tree, which he has to remember to manually
unstash after resolving conflicts in the merge (which would not have
conflicted with the local change anyway), which is an additional work for
no real gain, and (2) clutter his stash.  My gut feeling is that it is a
change that affects the way the end user has to work that is sufficiently
different and disruptive for no real gain.

If you read the original message more carefully, you will notice that the
suggested "git merge --abort" would break down *only* if the user messes
with the state conflicted merge left.  And an unmanageable conflicts are
much rare compared to most merges that autoresolve, so you should optimze
for the common case while giving a way to gain safety only when needed.

Probably a much better workflow, if we add "merge --abort", would be:

    $ edit ;# unrelated local changes are still here
    $ git pull ;# or merge or whatever
    ... oops, large conflict ...
    ... look and see if it can easily be resolved ...
    ... otherwise
    $ git merge --abort
    $ git stash
    $ git pull ;# or whatever, try again
    ... the same conflict but this time you only need to worry
    ... about the merge itself
    ... resolve, review, test to convince yourself that your
    ... resolution is good and then...
    $ git commit
    $ git stash pop

2009/2/20 Junio C Hamano [off-list ref]:
<snip>

   $ edit ;# unrelated local changes are still here
   $ git pull ;# or merge or whatever
   ... oops, large conflict ...
   ... look and see if it can easily be resolved ...
   ... otherwise
   $ git merge --abort

Can I just confirm - at this stage, "git merge --abort" would be a
"git reset --hard HEAD" ?

So could "git pull/merge" detect if there were local changes, and if
there are tell the user something along the lines that they have to
either abort the merge, or be unable to abort later?

   $ git stash
   $ git pull ;# or whatever, try again
   ... the same conflict but this time you only need to worry
   ... about the merge itself
   ... resolve, review, test to convince yourself that your
   ... resolution is good and then...
   $ git commit
   $ git stash pop

On Fri, Feb 20, 2009 at 12:24 AM, Junio C Hamano [off-list ref] wrote:

John Tapsell [off-list ref] writes:

quoted

2009/2/19 Jay Soffian [off-list ref]:

quoted

On Thu, Feb 19, 2009 at 8:34 AM, John Tapsell [off-list ref] wrote:

quoted

There's no reliable way of getting back to the state before the merge?

Sure there is. Commit or stash before you merge, so that your index
and working copy are clean.

Could a stash be done automatically by the merge command, for just a case?

It cuts both ways.  For people who work on a well organized project
(i.e. highly modularized) and tend to keep local changes in the work tree
while doing a lot of merges, running "stash" every time would (1) remove
the local change from the work tree, which he has to remember to manually
unstash after resolving conflicts in the merge (which would not have
conflicted with the local change anyway), which is an additional work for
no real gain, and (2) clutter his stash.  My gut feeling is that it is a
change that affects the way the end user has to work that is sufficiently
different and disruptive for no real gain.

Perhaps a better approach would be to stash the pre-merge state in the
reflog, then? That is, manufacture a pre-merge commit containing all
files changed in the working copy, and add it to the reflog prior to
performing a merge. git merge --abort can then simply check whether
the top reflog entry is a pre-merge state, and if so, reset --hard to
it, then reset the index to the parent of our pre-merge commit.

This would also nicely handle the case where the user tries some
random things before deciding to abort the merge.

Bryan Donlan [off-list ref] writes:

On Fri, Feb 20, 2009 at 12:24 AM, Junio C Hamano [off-list ref] wrote:

quoted

John Tapsell [off-list ref] writes:

quoted

2009/2/19 Jay Soffian [off-list ref]:

quoted

On Thu, Feb 19, 2009 at 8:34 AM, John Tapsell [off-list ref] wrote:

quoted

There's no reliable way of getting back to the state before the merge?

Sure there is. Commit or stash before you merge, so that your index
and working copy are clean.

Could a stash be done automatically by the merge command, for just a case?

It cuts both ways.  For people who work on a well organized project
(i.e. highly modularized) and tend to keep local changes in the work tree
while doing a lot of merges, running "stash" every time would (1) remove
the local change from the work tree, which he has to remember to manually
unstash after resolving conflicts in the merge (which would not have
conflicted with the local change anyway), which is an additional work for
no real gain, and (2) clutter his stash.  My gut feeling is that it is a
change that affects the way the end user has to work that is sufficiently
different and disruptive for no real gain.

Perhaps a better approach would be to stash the pre-merge state in the
reflog, then? That is, manufacture a pre-merge commit containing all
files changed in the working copy, and add it to the reflog prior to
performing a merge. git merge --abort can then simply check whether
the top reflog entry is a pre-merge state, and if so, reset --hard to
it, then reset the index to the parent of our pre-merge commit.

This would also nicely handle the case where the user tries some
random things before deciding to abort the merge.

Perhaps this is the case fo "feature that waits for a user", namely
'git stash --no-reset', which would save a state just in case, perhaps
in a separate area and not refs/stash (ORIG_STASH perhaps?).

What do you think about this idea?
-- 
Jakub Narebski
Poland
ShadeHawk on #git