GNU bug report logs - #20292
24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file

Previous Next

Full log

Message #22 received at 20292 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: esr <at> snark.thyrsus.com, 20292 <at> debbugs.gnu.org
Subject: Re: bug#20292: 24.5;
 Saving Git-controlled file with merge conflicts after "stash pop"
 stages the file
Date: Sun, 19 Apr 2015 17:30:21 +0300

> Date: Sun, 19 Apr 2015 00:58:47 +0300
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> CC: esr <at> snark.thyrsus.com, 20292 <at> debbugs.gnu.org
> 
> On 04/18/2015 10:31 PM, Eli Zaretskii wrote:
> 
> > It's best not to run "git add" in the first place in this case.
> 
> How will we detect it?

I suggested one method below; perhaps there are others, I simply don't
know enough about Git.

> And why would the user expect this difference in behavior? They'd
> either have a file nicely resolved, or the conflict unresolved,
> *and* a part of changes in staging area?

Stashed changes were uncommitted before, so they should stay
uncommitted after, I think.  Having them staged means the situation
after "stash pop" is different than it was before "stash save", which
I think is not what the user expects.

> > Why not detect that the conflict was from stashed changes?  This is
> > clearly stated at the last conflict marker.  The find-file-hook could
> > detect that and record the information.
> 
> It's more complicated, but sounds better if we prefer to detect 
> unstashing specifically, as opposed to any conflicts that were created 
> by a non-merge operation, I guess.

If there is a better way of doing that, fine.

> >> But what's the justification for vc-git-resolve-when-done?
> >
> > So that "git commit" would "just work", I presume.
> 
> A lot of problems start with someone wanting to make something "just work".

But sometimes "just works" is not a beginning of a problem.

> What if the user called 'git stash apply' instead of 'git stash pop'?

If you are questioning the wisdom of doing "stash drop", then this
question is not for me: it wasn't my suggestion.  If we are not sure
dropping the stash automatically is what the user wants, let's not
drop it, and leave management of stashes to the user.  It's not a big
deal to leave the stash behind, I think.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.