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 19:28:40 +0300

On 04/19/2015 05:30 PM, Eli Zaretskii wrote:

> I suggested one method below; perhaps there are others, I simply don't
> know enough about Git.

Apparently, we misunderstand each other. By "this case", do you mean 
when merging a stash in general?

Because I've described a more specific case (popping a stash when one 
has staged changes in one of the involved files), and it looked like you 
were referring to it in >>best not to run "git add" in the first place<<.

> Stashed changes were uncommitted before, so they should stay
> uncommitted after, I think.  Having them staged means the situation
> after "stash pop" is different than it was before "stash save", which
> I think is not what the user expects.

Right. And I meant the difference between what we do depending on 
whether user has something staged originally.

> If you are questioning the wisdom of doing "stash drop", then this
> question is not for me: it wasn't my suggestion.

You said "yes". I asked about this in the context of consistency; the 
question was about how far will we go to be consistent with Bzr, and 
whether it's feasible to do so, or we should stop at some point.

> If we are not sure
> dropping the stash automatically is what the user wants, let's not
> drop it, and leave management of stashes to the user.  It's not a big
> deal to leave the stash behind, I think.

It's not that big a deal to leave marking files as resolved to the user 
either. Am I right to understand that's what you're currently 
suggesting, at least when dealing with stashes?

This is easy (so, done).

Previous Next

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