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

[Dmitry Gutov <dgutov@yandex.ru>]

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.