Re: git annotate runs out of memory

From: Matthieu Moy <matthieu.moy@imag.fr>
Date: Dec 11, 2007, 23:37 UTC
Message-ID: <vpq63z49511.fsf@bauges.imag.fr>
In-Reply-To: <alpine.LFD.0.9999.0712111119310.25032@woody.linux-foundation.org>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 12 quoted lines

> On Tue, 11 Dec 2007, Matthieu Moy wrote:
>> 
>> I've seen you pointing this kind of examples many times, but is that
>> really different from what even SVN does? "svn log drivers/char" will
>> also list atomic commits, and give me a filtered view of the global
>> log.
>
> Ok, BK and CVS both got this horribly wrong, which is why I care. Maybe 
> this is one of the things SVN gets right.
>
> 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".

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/". As pointed out in other messages, the way it's done is really different from what git does. SVN does know a lot about directories, and records a lot about them at commit time, while git just considers them as file containers.

Year, CVS got this terribly wrong. IIRC, it just took the log for individual messages, and mix them together, so a commit touching multiple files would appear several times.

I've taken SVN as an extreme example, but at least bzr and mercurial have an approach very similar to git.

So, to me, this particular point is something git obviously got right, but not a point where git is so different from the others.

-- 
Matthieu