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

Previous Next

Full log

Message #166 received at 20292 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: esr <at> snark.thyrsus.com, 20292 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: Re: bug#20292: 24.5;
 Saving Git-controlled file with merge conflicts after "stash pop"
 stages the file
Date: Fri, 15 May 2015 21:55:44 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: dgutov <at> yandex.ru,  esr <at> snark.thyrsus.com,  20292 <at> debbugs.gnu.org
> Date: Fri, 15 May 2015 14:13:50 -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.

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

Previous Next

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