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