Re: [Bug] Stashing during merge loses MERGING state

On Thu, Mar 11, 2021 at 11:07 PM Chris Torek [off-list ref] wrote:

On Thu, Mar 11, 2021 at 9:19 PM Phil Hord [off-list ref] wrote:

quoted

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.

quoted

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.

You can use git-imerge (https://github.com/mhagger/git-imerge) for
that...just not once you've already started a merge (unless you're
willing to undo and restart).

As per my other email, I'm pretty worried about attempting to stash a
merge, given that stash allows its contents to be "reapplied" on top
of a different commit.  That works fine for single-parent commits, but
merges have multiple parents and it'd be rather tricky to reapply such
a stash on a different base without creating an evil merge.  Perhaps
if "superstash" forced you to only reapply on the same base then it'd
be fine...but it's starting to no longer be a "stash" anymore but
something else.