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

[Dmitry Gutov]

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