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

[Eli Zaretskii]

> Date: Sun, 19 Apr 2015 19:28:40 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: esr@snark.thyrsus.com, 20292@debbugs.gnu.org
> 
> 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?

I meant when "git stash pop" reports conflicts, in particular after a
"git pull" or "git merge".

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

I think we were talking about the same use case, but I cannot be sure,
since "has staged changes" might me more general than what I had in
mind.

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

Before "git stash save"?  The case I had in mind didn't have anything
staged before that.

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

Yes, because someone more knowledgeable than myself said it was a good
idea.

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

I think it's okay to leave the stash and not drop it in this case.

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

What does it mean to "mark files as resolved" when the conflict comes
from stashed changes that were uncommitted before "stash save"?