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

From: Jeff King <peff@peff.net>
Date: Dec 29, 2015, 07:53 UTC
Message-ID: <20151229075329.GA9254@sigill.intra.peff.net>
In-Reply-To: <20151224092038.GA2397@acm.fritz.box>

On Thu, Dec 24, 2015 at 09:20:38AM +0000, Alan Mackenzie wrote:

Show 14 quoted lines

> > It seems to be a side effect of merge-recursive to stage the results,
> > and in the no-conflict path we explicitly reset the index. For the
> > conflicting case, it's trickier, because we would want to retain the
> > unmerged entries.
> 
> > So I agree it's kind of weird, but the conflicting case is inherently
> > going to touch the index, and you'd generally have to `git add` to mark
> > the resolutions (but if you really want to just touch the working tree,
> > you'd need to `git reset`).
> 
> From the point of view of a user, this is suboptimal.  git stash is an
> abstraction: the preservation of uncomitted changes for later.  Staging
> previously unstaged changes with git stash pop severely damages this
> abstraction.

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

> Are there any prospects of this getting fixed?

Somebody needs to write a patch. I am not 100% convinced that it _should_ be fixed, but I am leaning that way. But I am not planning to work on it myself anytime soon. The best way to get more discussion going is to post a patch. :)

-Peff