Re: "git stash pop" is doing an unwanted "git add" when there are conflicts.

From: Jeff King <peff@peff.net>
Date: Dec 30, 2015, 07:02 UTC
Message-ID: <20151230070238.GA29896@sigill.intra.peff.net>
In-Reply-To: <20151229212038.GD1884@acm.fritz.box>

On Tue, Dec 29, 2015 at 09:20:38PM +0000, Alan Mackenzie wrote:

Show 9 quoted lines

> > Yeah, I think I agree. But keep in mind that we have to mention the
> > conflicts _somewhere_, so we're going to touch the index regardless (and
> > the user is going to have to erase the conflicts in the index
> > eventually, either with `git add` or `git reset`).
> 
> When the stash consists entirely of changes in the working directory,
> and "git stash pop" has conflicts, why can't these conflicts simply be
> marked by "<<<<<<<<" (etc.) in the working directory, leaving the index
> unchanged?  The index is left unchanged when there are no conlicts.

I don't think that's a good idea. Git always marks conflicts in the index for other operations. Besides being inconsistent with the rest of git, it drops useful information that other tools can use. For example, one cannot "git checkout --conflict=diff3" afterwards, or use "git mergetool" to kick off a third-party merge tool.

Not to mention that the information is lost to the user themselves. If we touched 10 files and 2 had conflicts, there is now no way for the user to ask "where were the conflicts?". They can either find the stash output in their terminal scrollback, or grep for things that look like conflict markers.

-Peff