Re: [Bug] Stashing during merge loses MERGING state

On Thu, Mar 11, 2021 at 12:45 PM Tassilo Horn [off-list ref] wrote:

quoted

quoted

Or that popping the stash again would also restore the MERGING state.

This would make more sense: the stash records that part of the state,
and then we make it available again later when the stash is applied.
However, that feature doesn't exist yet.

Too bad.

Consider also what happens when `git stash apply` results in a merge
conflict because of differences between your current index and the one
you had when you originally saved the stash.  This results in the
usual merge conflict markers that then need to be cleaned up.

Could we sanely deal with this in a world where we also tried to
restore .git/MERGE_HEAD when the stash was applied. Something like
`git stash apply --continue`, possibly after resolving the stash
conflicts?  But what if we stashed the merge conflict that resulted
from the stash apply?  I guess it would still work, but the stash
history would be, um, interesting.

I wonder if a fix could be as simple as recording the MERGE_HEAD as
the third parent commit of the stash ref. I think that would provide
all the information needed to put things back, except possibly for
things like the rerere state, which is also set up during a conflict,
and other incidentals like .git/MERGE_MSG.  (And it feels like it
might break compatibility with older versions that don't expect a
third parent.)

I would be a bit concerned about the possibility of silently creating
an "evil merge".  Suppose you stash this conflict on some branch and
then pop it onto a different one.  I expect we would then be prepared
to store all those changes from a different branch including existing
resolved merge conflicts into the new one.  That could be surprising
and subtle.

But maybe I'm overthinking it.  Wouldn't the stash apply result in
merge conflicts that would catch out all the troubling parts?

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.

Thanks for raising the issue, Tassilo.  This has obviously given me
more ideas for things I forgot were missing.

quoted

I can't offhand think of a reason it couldn't be implemented. It's
possible that it would mess with somebody else's workflow (e.g., they
think it's useful to stash some changes independent of the merging
state, and then apply it later, perhaps while replaying the same or a
similar merge). So it might need to be tied to a command-line option
or similar.

Everything breakes someones workflow [1], so an option would be fine.

However, I'd suggest to protect users shooting in their foot with a
warning and confirmation query for the time being.  I consider myself a
quite experienced git user but this stash trouble today came totally
unexpected.  And I've asked on #git@irc.freenode.net and got no answer
which is totally uncommon.  So I guess that this stash during merge
thing is pretty much a gray area.

I don't think we could easily add the warning when the stash is
applied since we have forgotten the merge existed in the first place.
So we would have to do it during stash save.

"Warning: You are stashing during a merge conflict and your merge
state will not be restored by stash apply."

Seems reasonable.

Phil