Re: git annotate runs out of memory

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Dec 11, 2007, 23:48 UTC
Message-ID: <alpine.LFD.0.9999.0712111544390.25032@woody.linux-foundation.org>
In-Reply-To: <vpq63z49511.fsf@bauges.imag.fr>

On Wed, 12 Dec 2007, Matthieu Moy wrote:

Show 9 quoted lines

>
> > 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