Hi, On Wed, 11 Feb 2009, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > Even the merging should not pose any problem at all; we need a custom > > merge driver anyway, and there is no reason whatsoever why we should > > not just teach the merge driver to remove the slashes before comparing > > the filie names. > > Once you start talking about "remove the slashes", you are assuming that > the custom merge algorithm must look at *all the paths* in the two trees > being merged, and it is a sign that your thinking is so trapped in the > inefficient way the current merge-recursive and unpack-trees based merge > works, and cannot think about the possibility that there could be more > efficient way to do merges. Not very good. > > If you have a fixed boundary and if most subtrees are the same between > two notes during a merge, we can do the same optimization as we do for > two input "diff-tree" codepath. If the top of a subtree matches, we do > not even have to look at their subtree. But that is true only if you do > not remove the slashes and allow a random hierarchy. Well, I think in the case of notes, we have to optimize for random access of dozens of blobs rather than for merging. I was well aware that the merging is more expensive when the hierarchy is not defined a priori. Ciao, Dscho -- 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
