Bryan Donlan <bdonlan@xxxxxxxxx> writes: > On Fri, Feb 20, 2009 at 12:24 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> John Tapsell <johnflux@xxxxxxxxx> writes: >>> 2009/2/19 Jay Soffian <jaysoffian@xxxxxxxxx>: >>>> On Thu, Feb 19, 2009 at 8:34 AM, John Tapsell <johnflux@xxxxxxxxx> 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. 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
