Pierre Habouzit <madcoder@xxxxxxxxxx> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
