Re: [RFC/PATCH 2/2] stash: drop dirty worktree check on apply

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 5, 2011, 21:59 UTC
Message-ID: <7vvcysl5pz.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20110405212314.GA3613@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 11 quoted lines

> However, this check has two problems:
>
>   1. It is overly restrictive. If my stash changes only file
>      "foo", but "bar" is dirty in the working tree, it will
>      prevent us from applying the stash.
>
>   2. It is redundant. We don't touch the working tree at all
>      until we actually call merge-recursive. But it has its
>      own (much more accurate) checks to avoid losing working
>      tree data, and will abort the merge with a nicer
>      message telling us which paths were problems.

I _think_ the reason we originally insisted on clean working tree was that while merge-resolve has always had an acurate check, merge-recursive's check was not very good, especially when renames are involved. So probably this part of your comment ...

> I'm not sure if the check was perhaps even required when git-stash was
> written, and has simply since become useless as merge-recursive became
> more careful.

... may need to be used to rewrite bullet 2. above.

This is a tangent, but I notice that the additional bolted-on codepath for the --index option has this:

    git diff-tree --binary $s^2^..$s^2 | git apply --cached

It might want to do -B -M to match what "git merge-recursive" does.