From: Bryan Donlan Date: Sat, 21 Feb 2009 07:28:27 GMT Subject: Re: git merge --abort Message-ID: <3e8340490902202328r7caca98q973c17dc163e2028@mail.gmail.com> In-Reply-To: <7v7i3lk7dp.fsf@gitster.siamese.dyndns.org> On Fri, Feb 20, 2009 at 12:24 AM, Junio C Hamano wrote: > John Tapsell writes: > >> 2009/2/19 Jay Soffian : >>> On Thu, Feb 19, 2009 at 8:34 AM, John Tapsell 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.