On Tue, 26 Apr 2005, Linus Torvalds wrote: > > > What I'd really like to hear is some explanation of why git is > > reimplementing all of this stuff from scratch. > > Git does in ~5000 lines and two weeks of work what _I_ think is the right > thing to do. You're welcome to disagree, but the fact is, people have > whined and moaned about my use of BK FOR THREE YEARS without showing me > any better alternatives. Btw, I've also been pretty disgusted by SCM's apparently generally caring about stuff that is totally not relevant. For example, it seems like most SCM people think that merging is about getting the end result of two conflicting patches right. In my opinion, that's the _least_ important part of a merge. Maybe the kernel is very unusual in this, but basically true _conflicts_ are not only rare, but they tend to be things you want a human to look at regardless. The important part of a merge is not how it handles conflicts (which need to be verified by a human anyway if they are at all interesting), but that it should meld the history together right so that you have a new solid base for future merges. In other words, the important part is the _trivial_ part: the naming of the parents, and keeping track of their relationship. Not the clashes. For example, CVS gets this part totally wrong. Sure, it can merge the contents, but it totally ignores the important part, so once you've done a merge, you're pretty much up shit creek wrt any subsequent merges in any other direction. All the other CVS problems pale in comparison. Renames? Just a detail. And it looks like 99% of SCM people seem to think that the solution to that is to be more clever about content merges. Which misses the point entirely. Don't get me wrong: content merges are nice, but they are _gravy_. They are not important. You can do them manually if you have to. What's important is that once you _have_ done them (manually or automatically), the system had better be able to go on, knowing that they've been done. Linus - 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 Wed Apr 27 07:23:19 2005
This archive was generated by hypermail 2.1.8 : 2005-04-27 07:23:20 EST