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: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: esr <at> snark.thyrsus.com, 20292 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file
Date: Fri, 15 May 2015 16:02:03 -0400

>> > That's not the use case we were discussing, though.  We were
>> > discussing a use case where the user merged from another repository,
>> > and then wants her uncommitted changes restored.  Leaving them staged
>> > will trip the naive users.
>> But Emacs is not the main culprit: Git itself will stage all the
>> non-conflicting changes, so why should this not trip the user similarly?
> The users I have in mind expect Emacs to save them from Git
> idiosyncrasies.

I don't see how that's relevant.  By behaving differently from the rest
of Git, I'm afraid we'll just introduce more problems.

>> IOW if the user gets tripped by Emacs doing "git add" after resolving
>> a unstash conflict, why would that same user not already be tripped
>> identically by Git doing this "git add" on the non-conflicted files?
> Because they don't use Git from the shell, or at least try not to.

Feel free to change the behavior of vc-git-resolve-when-done for the
case where the unstash was done from within Emacs after you've changed
this unstash to behave the way you want it, rather than the way Git
does it.

In my case, the unstash is done by Git with no Emacs involvement, and in
that case it seems that "git add" is just the only sane thing to do.


        Stefan

Previous Next

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