Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > On Fri, 20 Oct 2006, Linus Torvalds wrote: > >> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Sat Oct 21 12:18:01 2006
This archive was generated by hypermail 2.1.8 : 2006-10-21 12:19:02 EST