On Thu, Mar 11, 2021 at 9:19 PM Phil Hord <phil.hord@xxxxxxxxx> wrote: > I wonder if a fix could be as simple as recording the MERGE_HEAD as > the third parent commit of the stash ref. There is already a third parent, but only when using -u / -a: this third-parent commit holds the untracked files (which are then removed a la `git clean`). A better trick would, I think, be able to save a partial merge state in general, including the unmerged statuses of various files, the ongoing action (merge or one of the other things that use it), and so on, in a form that could be restored later. A plain `git stash` in any partially-merged state should tell you: no, use the fancier merge-state-saver instead. > I think being able to stash during a merge conflict could be very > useful. I do sometimes need to get back to a working state > momentarily and a merge conflict represents a long pole to doing so. > Similarly, it could be useful to stash a conflicted `git rebase` so I > could return to it later and pick up where I left off. Now we really > would need to store some extra metadata, though, like the todo-list > and ORIG_HEAD. And we would definitely need some extra command line > switch to tell stash (or rebase) that I want to include all the rebase > state and also "pause" the rebase by restoring to my starting point. This is the sort of thing I'm thinking of, for the "superstash" (terrible name for it). Note that whatever this becomes, it should be send-able (via push and/or email) so that you can have multiple people work on resolving a particularly hairy merge. Chris
