On Wed, 12 Dec 2007, Matthieu Moy wrote: > > > I seriously doubt it, though. Do you get *history* right, or do you just > > get a random list of commits? > > Well, you don't get merge commit right with SVN, but that's a > different issue (svn 1.5 is supposed to have something about merge > history, I don't know how it's done ...). So, if by "history", you > mean how branches interferred together, obviously, SVN is bad at this. > But it's equally bad at "svn log dir/" and plain "svn log". Yeah, git just has higher goals. The time history really matters (or rather, what I call the "shape" of history) is when you are trying to merge, and you get a merge conflict. That's when you want to do gitk master merge ^merge-base -- files-that-are-unmerged and in fact this is such an important thing for me that there is a shorthand argument to do exactly that, ie: gitk --merge which shows the commits that touched the unmerged files graphically *with* the history being correct (ie you don't just get a random log of "these changes happened", you get the real history of the two branches as it pertains to the files you care about!) > But to simplify, if you take a linear history (no merge commits), > "svn log dir/" give you the list of commits which changed something > inside "dir/" Sure, linear history is trivial. But it's also almost totally uninteresting. 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
