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

From: Jeff King <peff@peff.net>
Date: Apr 22, 2015, 19:55 UTC
Message-ID: <20150422195513.GC27656@peff.net>
In-Reply-To: <xmqq8udkdk1a.fsf@gitster.dls.corp.google.com>

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

Show 11 quoted lines

> Jeff King <peff@peff.net> 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.

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.

Show 6 quoted lines

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

Show 5 quoted lines

> > 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