Re: How do I resolve conflict after popping stash without adding the file to index?

Jeff King [off-list ref] writes:

Ironically, the message before e0e2a9c actually recommends staging
changes before applying the stash, which would lead to this exact
situation!

The ancient history is hazy to me, but did we fall back to three-way
merge in old days (or did anything to the index for that matter), I
wonder?  In a world "git stash apply" only applied the change to the
working tree via "git apply", that old recommendation would make
perfect sense.

But obviously we do not live in such a world right now.  And because
we are doing "merge-recursive", we should insist on a clean index;
otherwise there is no way to "undo" its effect without losing the
changes by the end-user.

Yes, that makes sense.  The original report from Dmitry was
triggering the safety from one line above and "git stash pop" doing
the right thing by refusing to touch the index with unresolved mergy
operation before doing anything, and with this additional safety, we
would make it even safer from people who do "git add" and then "git
stash pop" (which is somewhat strange thing to do, given that
"stash" was designed for "stash to save away; do other things; come
back to the original commit state that is 'reset --hard' clean;
unstash" sequence in the first place).

 	# current index state
 	c_tree=$(git write-tree) ||

but it makes me wonder if somebody would find it annoying that they
cannot apply a stash into their work-in-progress (i.e., it _might_ cause
annoyance, but most of the time it will be convenient to do so).

They can always do "git stash show -p stash@{n} | git apply" if they
want to build changes incrementally X-<, but it would be annoying.

So probably we'd want to refactor that into two separate functions, and
only call the require_clean_index part.

Hmph, but what would that helper do, other than a single "diff-index
--quiet --cached HEAD" call?

On Wed, Apr 22, 2015 at 12:45:21PM -0700, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

Ironically, the message before e0e2a9c actually recommends staging
changes before applying the stash, which would lead to this exact
situation!

The ancient history is hazy to me, but did we fall back to three-way
merge in old days (or did anything to the index for that matter), I
wonder?  In a world "git stash apply" only applied the change to the
working tree via "git apply", that old recommendation would make
perfect sense.

Hmm, that advice came in 2a79d2f (Clarify how the user can satisfy
stash's 'dirty state' check., 2008-09-29), at which point it looks like
we were already running merge-recursive. So I think it was simply bad
advice. ;)

But obviously we do not live in such a world right now.  And because
we are doing "merge-recursive", we should insist on a clean index;
otherwise there is no way to "undo" its effect without losing the
changes by the end-user.

Yeah, agreed.

quoted

but it makes me wonder if somebody would find it annoying that they
cannot apply a stash into their work-in-progress (i.e., it _might_ cause
annoyance, but most of the time it will be convenient to do so).

They can always do "git stash show -p stash@{n} | git apply" if they
want to build changes incrementally X-<, but it would be annoying.

I think the best thing to do is introduce this safety, let it cook for a
while, and see what comes up. Perhaps we could add a "--force" or
similar, but I'd rather see if anybody ever actually runs into the
situation first.

quoted

So probably we'd want to refactor that into two separate functions, and
only call the require_clean_index part.

Hmph, but what would that helper do, other than a single "diff-index
--quiet --cached HEAD" call?

I was wanting to keep the error message and the flags we feed to
diff-index consistent. But yeah, there is little enough duplicate
material and enough added boilerplate that I do not think it is worth it
(see the series I just posted).

-Peff