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

[Eli Zaretskii]

> Date: Sun, 19 Apr 2015 00:58:47 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: esr@snark.thyrsus.com, 20292@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.