Re: git annotate runs out of memory

Pierre Habouzit [off-list ref] writes:

quoted

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.