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, 20292 <at> debbugs.gnu.org
Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file
Date: Sun, 19 Apr 2015 00:58:47 +0300

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

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

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

> That would mean VC behaves wit Git differently than it does with other
> VCSes (bzr, at least).

You mean smerge-mode, not VC, right? How come? I don't even see

> Yes.

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

> Although IME, Git itself does that when you resolve the last
> conflict.  But I'm not going to claim that this is 100% accurate, just
> that it happened to me when I needed to resolve conflicts from stash.

I didn't when I tried it, a couple of times.

Previous Next

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