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

[Jeff King <peff@github.com>]

On Tue, Apr 05, 2011 at 02:59:36PM -0700, Junio C Hamano wrote:

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

That makes sense to me. I'd be a lot more comfortable if I could find
the actual place where merge-recursive got more accurate. I'll see if
it's simple to bisect.

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

Yeah, that sounds sensible to me.

-Peff