Re: [Bug] Stashing during merge loses MERGING state

[Junio C Hamano <gitster@pobox.com>]

Phil Hord <phil.hord@gmail.com> writes:

> On Thu, Mar 11, 2021 at 12:45 PM Tassilo Horn <tsdh@gnu.org> wrote:
>> >> 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.