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). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html