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

[Alan Mackenzie <acm@muc.de>]

Hello, Jeff.

On Tue, Dec 29, 2015 at 02:53:30AM -0500, Jeff King wrote:
> On Thu, Dec 24, 2015 at 09:20:38AM +0000, Alan Mackenzie wrote:

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

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.

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

Hmm.  I would very much prefer to remain just a user of git.

> -Peff

-- 
Alan Mackenzie (Nuremberg, Germany).