Re: git-merge-recursive, was Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle

Johannes Schindelin [off-list ref] writes:

On Fri, 20 Oct 2006, Linus Torvalds wrote:

quoted

Git just slurps in all three trees. I actually think that the current 
merge-recursive.c does it the stupid way (ie it expands all trees 
recursively, regardless of whether it's needed or not), but I should 
really check with Dscho, since I had nothing to do with that code.

AFAIR yes, it does the dumb thing, namely it does not take advantage of 
trees being identical when their SHA1s are identical.

This will be a _tremendous_ speed-up.

While we are talking about merge-recursive, I could use some
help from somebody familiar with merge-recursive to complete the
read-tree changes Linus mentioned early this month.

The issue is that we would want to remove one verify_absent()
call in unpack-tree.c:threeway_merge().  When read-tree decides
to leave higher stages around, we do not want it to check if the
merge could clobber a working tree file, because having an
unrelated file at the same path in the working tree sometimes is
and sometimes is not a conflict, depending on the outcome of the
merge, and that part of the code does not _know_ the outcome
yet.

What this means is that we would need to have the equivalent
check in the merge strategy that uses read-tree for three-way
merge when we remove this overcautious safety check from
read-tree.  I've adjusted merge-one-file to do so, but not many
people use 'resolve' strategy these days, and we would need the
matching change in merge-recursive.

If you are interested, you can see the details in commit 0b35995.