Bernt Hansen <bernt@xxxxxxxxx> writes: > Junio C Hamano <gitster@xxxxxxxxx> writes: > ... >> 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 -- 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
