Re: git log -S doesn't find some commits

Bernt Hansen [off-list ref] writes:

Junio C Hamano [off-list ref] writes:
...

quoted

There seems to be a misconception on what -S<foo> does.  It does *NOT*
grep for string <foo> in the patch text.  It counts number of <foo> in
preimage and postimage and decides that the commit is worth showing iff
they differ.

If you look at, for example (B):

    http://repo.or.cz/w/org-mode.git?a=commitdiff;h=837c81ce51

You can see that in org-publish.el, org-publish-validate-link appears once
as removed and once as added, so the total number of the appearance of the
symbol in preimage and postimage are the same.

Now I get it :)

Thanks both of you!

By the way, I would not be opposed to a new feature, perhaps triggered
with -G<foo>, that acts as if it is grepping inside the patch text.

The reason behind -S<foo>'s behaviour is because it was designed as a part
ofa "incremetal digging" tool before the current "git-blame" that allows
to track even line-movements.

That is, you could write a tool to help the following interactively:

 (1) get interested in a block of text in a recent version;

 (2) feed that to 'git log' like this:

 	git log -1 -p -S"$potentially_multi_line_text" $rev

     this will find an old rev R whose parent R^ did not have the lines
     in the exact form you fed with -S.

 (3) inspect the output, and decide what to do next:

     (3-a) you may want to adjust the text you look for, taking into
     account how the neighbouring lines used to look like in R^, and run
     another "git log -S" starting at R^; and/or

     (3-b) you may want to run "git grep" for the text in the entire
     tree in R^, to see if this was a code refactoring that consolidates
     multiple copies of the same thing into a single place.

     and go back to step (2).


cf. http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217