Re: git annotate runs out of memory

[Linus Torvalds <torvalds@linux-foundation.org>]

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