Re: git rebase chokes on directory -> symlink -> directory

From: Junio C Hamano <junkio@cox.net>
Date: May 11, 2007, 17:28 UTC
Message-ID: <7vfy63b789.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <alpine.LFD.0.98.0705110835230.3986@woody.linux-foundation.org>

Linus Torvalds <torvalds@linux-foundation.org> writes:

> That said, wouldn't it potentially be quite easy in "unpack_trees_rec()" 
> to just notice when all the trees are identical, and just not recurse at 
> all in that case (or - alternatively - recurse, but on entry, just exit 
> quickly?)

In the threeway case, it should be able to notice that the trees of the ancestor and the other match, which is the only case we can safely say that the result will be our tree (aka HEAD) and we won't mess with the index nor worry about local modifications made only to the working tree. The case in which all trees match, regardless of the number of trees involved, should work the same way.

However, in the threeway case, we still need to make sure that the index matches the HEAD even when we know the result will be taken from HEAD, as otherwise we would end up including the local "git add" made earlier in the merge result. We need to make sure the index matches HEAD for such a subdirectory in that case before skipping it.

What is troublesome is that kind of policy logic is not supposed to happen in unpack_trees_rec() in the current code structure; instead, that decision is to be made by o->fn().

So, I am not sure if it is that quite easy.