Re: [Bug] Stashing during merge loses MERGING state

Phil Hord [off-list ref] writes:

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

quoted

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.

I agree with you that allowing a stash while a merge is in progress
will introduce many unpleasant corner cases the users wouldn't want
to deal with.  We certainly do prevent "git stash push" from running
when the index is still unmerged (which is a sign that a mergy
operation (like pull, rebase, merge, am -3, cherry-pick and revert
that stops due to a conflict in the middle) is in progress), but
once the end user resolves the conflicts in the index (either
manually, or having the rerere.autoupdate feature in effect), such a
sign of mergy operation still in progress that "git stash" currently
uses will be gone.  We should teach "git stash push" to pay
attention to other such signs like MERGE_HEAD etc. and stop before
creating a stash (and also do the same to "git stash pop/apply").

THanks.

On Thu, Mar 11, 2021 at 10:15 PM Junio C Hamano [off-list ref] wrote:

Phil Hord [off-list ref] writes:

quoted

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

quoted

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.

I agree with you that allowing a stash while a merge is in progress
will introduce many unpleasant corner cases the users wouldn't want
to deal with.  We certainly do prevent "git stash push" from running
when the index is still unmerged (which is a sign that a mergy
operation (like pull, rebase, merge, am -3, cherry-pick and revert
that stops due to a conflict in the middle) is in progress), but
once the end user resolves the conflicts in the index (either
manually, or having the rerere.autoupdate feature in effect), such a
sign of mergy operation still in progress that "git stash" currently
uses will be gone.  We should teach "git stash push" to pay
attention to other such signs like MERGE_HEAD etc. and stop before
creating a stash (and also do the same to "git stash pop/apply").

THanks.

I should have read the rest of the emails before responding.  Once
again, you manage to say roughly what I was thinking, but do so both
more concisely and more eloquently.