Re: git merge --abort

[Bryan Donlan <bdonlan@gmail.com>]

On Fri, Feb 20, 2009 at 12:24 AM, Junio C Hamano <gitster@pobox.com> wrote:
> John Tapsell <johnflux@gmail.com> writes:
>
>> 2009/2/19 Jay Soffian <jaysoffian@gmail.com>:
>>> On Thu, Feb 19, 2009 at 8:34 AM, John Tapsell <johnflux@gmail.com> wrote:
>>>> 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.