All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tassilo Horn <tsdh@gnu.org>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [Bug] Stashing during merge loses MERGING state
Date: Thu, 11 Mar 2021 21:31:09 +0100	[thread overview]
Message-ID: <87a6r9o1yo.fsf@gnu.org> (raw)
In-Reply-To: <YEpusE7ZIE5RgOws@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Hi Jeff,

>> What did you expect to happen? (Expected behavior)
>> 
>> I expected that stashing during a merge will keep the MERGING state.
>
> Thanks for providing a clear recipe and expectation. However, I think
> Git is working here as intended. The MERGE_HEAD file (which is how "git
> status", the prompt, etc figure out that we're in the middle of a merge)
> is cleaned up when stash runs "git reset --hard" under the hood.
>
> However, I don't think we would want to _not_ clear that file. The
> conflicted merge placed some changes into the index and working tree
> representing what happened on the branch you're merging in. Then
> making the stash (and the reset of the working tree) removes those
> changes. If we were to leave MERGE_HEAD in place and you ran "git
> commit", then it would create a merge commit that claims to have
> incorporated everything from the other branch, but has quietly dropped
> those changes as part of the merge resolution.

Yes, that makes sense.

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

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

Bye,
Tassilo

[1] https://xkcd.com/1172/

  reply	other threads:[~2021-03-11 20:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-11 14:00 [Bug] Stashing during merge loses MERGING state Tassilo Horn
2021-03-11 19:25 ` Jeff King
2021-03-11 20:31   ` Tassilo Horn [this message]
2021-03-12  5:00     ` Phil Hord
2021-03-12  6:09       ` Junio C Hamano
2021-03-12  7:04         ` Elijah Newren
2021-03-12  7:02       ` Chris Torek
2021-03-12  7:17         ` Elijah Newren
2021-03-12  7:02       ` Elijah Newren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a6r9o1yo.fsf@gnu.org \
    --to=tsdh@gnu.org \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.