From: Junio C Hamano <gitster@pobox.com>
Date: Tue, 11 Dec 2007 19:59:29 GMT
Subject: Re: git annotate runs out of memory
Message-ID: <7vve75c89q.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20071211193407.GC20644@artemis.madism.org>

Pierre Habouzit <madcoder@debian.org> writes:

>> Looking through thousands of diffs to find the one that happened to
>> your line is also pretty annoying.
>
>   If the question you want to answer is "what happened to that line"
> then using git annotate is using a big hammer for no good reason.
>
> git log -S'<put the content of the line here>' -- path/to/file.c
>
> will give you the very same answer, pointing you to the changes that
> added or removed that line directly. It's not a fast command either, but
> it should be less resource hungry than annotate that has to do roughly
> the same for all lines whereas you're interested in one only.
>
> The direct plus here, is that git log output is incremental, so you have
> answers about the first diffs quite quick, which let you examine the
> first answers while the rest is still being computed.

Yes.

> Unlike git annotate, this also allow you to restrict the revisions
> where it searches to a range where you know this happened, which makes
> it almost instantaneous in most cases.

Yes, but blame also takes revision bottoms (obviously you have to start
digging from a single revision so "blame master..next pu" would not
work, but "blame ^foo ^bar baz" would).

> Of course, if the line is '    free(p);\n' then you will probably have
> quite a few false positives,...

You can feed more than a line from -S, and the assumed and recommended
typical use case is to do so.

> Note that it does not justifies the current memory consumption that just
> looks bad and wrong to me,...

Right.