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