On Tue, Apr 05, 2011 at 02:59:36PM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html