On Wed, Apr 22, 2015 at 12:45:21PM -0700, Junio C Hamano wrote:
> Jeff King <p...@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.
> > 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.
> > 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
