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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: monnier@iro.umontreal.ca, esr@snark.thyrsus.com, 20292@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 13 May 2015 02:13:10 +0300
> 
> When a stash contains changes for several files, and "stash pop" encounters conflicts only in some of them, the rest of the files are stages automatically.
> 
> At least, that happens with Git 2.1.0 on my machine

I see this with 1.9.5 as well.

> What shall we do?

Report a bug in Git, I think.  It doesn't make sense to have the
outcome of "stash pop" wrt the index/staging depend on whether there
were conflicts or not, which is what happening here: if I "stash pop"
after pulling when none of my local stashed changes are in conflict
with the pulled/merged content, I get back modified and unstaged
files.  Why would the existence of conflicts during "stash pop"
produce any different effect for files _without_ conflicts, except by
some obscure bug?

> Unstage the automatically-staged files?

If we can do that, yes.  But how do we know which files to unstage?

> Revert the changes from this bug?

No!  That'd be a step back.  The current treatment of stashed changes
is better than it was before the change.  Also note that conflicts
like this are quite rare, so the way vc-git worked previously was
wrong in 99% of cases, why the one we have now is wrong in perhaps
0.1%.

> It seems Git really wants the changes staged after the conflict resolution.

It seems to me we've uncovered a bug in Git (gasp!).  Git has no
reasons to want the changes staged, certainly not depending on whether
there were conflicts.