Re: [Bug] Stashing during merge loses MERGING state

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 12, 2021, 06:09 UTC
Message-ID: <xmqq5z1wc389.fsf@gitster.g>
In-Reply-To: <CABURp0pFdHAx_+-e+O35Qxtbe3_+cZy9SZcOSeR2R7v_neRwKg@mail.gmail.com>

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

Show 13 quoted lines

> 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.