On Fri, 20 Oct 2006, Jakub Narebski wrote: > Jan Hudec wrote: > > > And note, that it is /not/ required to use file-ids to handle this. > > Darcs handles this just as well with it's patch algebra > > (http://darcs.net/DarcsWiki/PatchTheory) without need of any IDs. > > And Darcs is, from opinions I've read, dog-slow. You really cannot expect to get any kind of performance at all unless you: - are able to ignore 99.9% of all files on merging (ie you have to be able to totally ignore the files that are identical in both sides, and you really shouldn't even _care_ about why they ended up being identical) - are able to ignore 99% of what the commits _did_ in between the merges (ie if you need to look at them at all, only look at the part that matters for the 0.1% of files that you couldn't ignore) If you have to parse all the commit details all the way down to the common parent, you're basically already screwed. There's no _way_ you can make it fast. Git goes one step further: it _really_ doesn't matter about how you got to a certain state. Absolutely _none_ of what the commits in between the final stages and the common ancestor matter in the least. The only thing that matters is what the states at the end-point are. (Of course, you _could_ plug in a merge algorithm that cares, since there is more data there. I'm just talking about the standard "recursive" algorithm here.) That's why git can be so fast, but it's actually more important than that: the fact that it doesn't matter _how_ you got to a certain state is actually a huge and important feature. In other words, you should see it as a guarantee, not as a "lack of knowledge". Darcs thinks it matters how you got somewhere. Git consciously says: none of the individual patches matter, the only thing that matters is the end result, because you could have gotten the same result in a lot of different ways, and nobody _cares_. Linus - 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