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

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: esr <at> snark.thyrsus.com, monnier <at> iro.umontreal.ca, 20292 <at> debbugs.gnu.org
Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file
Date: Thu, 14 May 2015 04:24:12 +0300

On 05/13/2015 07:18 PM, Eli Zaretskii wrote:

> Report a bug in Git, I think.

I believe it's your turn to report a Git bug now. ;)

Still, even if it's fixed, we'll have a lot of users, for years to come, 
that use Git without that fix. Note how you and I are using quite 
different versions, and the latest release is 2.4.1.

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

As a wild guess, maybe the files that get staged automatically are the 
result of automatic conflict resolution (there was some divergence, but 
it was resolved automatically; maybe the "no divergence" case is also 
treated like this, for simplicity). IOW, the "worse is better" kind of 
reasons.

>> Unstage the automatically-staged files?
>
> If we can do that, yes.  But how do we know which files to unstage?

That the the difficulty: right after applying the stash we could know 
(all of them!), but Emacs can't know whether the user staged anything 
else between then and now (when all conflicts have been resolved). IOW, 
the user is better positioned to call 'git reset'.

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

I don't know where you got the percentages. My stashes routinely touch 
multiple files, and it's easy to imagine how not all of them could have 
conflicts after applying.

The odds are hard to calculate, but the probability really must be in 
tens of percents, not below one.

The current behavior is bad because it looks random. It would look 
especially random to someone who's used to interact with Git via 
command-line.

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

Staging changes is the Git way to mark conflict as resolved. Ergo, it 
expects the conflicting files to be staged after the user resolves the 
conflicts. Then it won't make a lot of sense to leave the rest of the 
files unstaged, would it? Maybe that's the reasoning.

It's hard for me to tell without knowing exactly why Git conflates 
conflict resolution and staging.

Previous Next

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