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 #31 received at 20292 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#20292: 24.5; Saving Git-controlled file with merge
 conflicts after "stash pop" stages the file
Date: Sun, 19 Apr 2015 20:38:30 +0300

On 04/19/2015 08:06 PM, Eli Zaretskii wrote:

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

That's the general case.

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

No: it's more specific. Before you do 'git stash pop', either there's 
nothing in the staging area (and the conflict is most likely due to some 
new commits), or there is something in the staging area.

"one has staged changes in one of the involved files" means the latter.

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

No, after "git stash save", but before "git stash pop".

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

It was a question. :)

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

Changes that were staged, but then put into stash is a whole new 
different wrinkle. Luckily, 'git stash pop' only concerns itself with 
that distinction when passed a '--index' argument.

Previous Next

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