git log -S doesn't find some commits

Hi!

The org-mode repository at git://repo.or.cz/org-mode.git has history that looks like this:

                  o--o--o--o-------------------M--F--o-- .. --o master
                 /                            /
 A--o-- .. --o--o-------------o--o--B--C--X--D

where commits A, B, C, D, and F all modify lines with 'org-publish-validate-link'. M is a merge commit and X has an empty log message.

$ git checkout 8ea076e2de2b3721bd813ea5a2df1b53d0c25055 # commit F $ git log -Sorg-publish-validate-link

reports 3 commits

F, A, and something earlier than A

Commits B, C, and D are not included in the git log -S output even though with gitk you can see that 'org-publish-validate-link' is in the patch.

Am I doing something wrong or is this a bug?

$ git --version git version 1.6.0.3.523.g304d0

I've marked the commits in column one below.

  $ git log --pretty=oneline

F 8ea076e2de2b3721bd813ea5a2df1b53d0c25055 Updated org-publish.el (now version 1.8
  e322abfd14267a154a06deb1e7ef5a432b17f68a Merge branch 'add-recursion-to-org-publ
  6208fb43cb1bbab852560cf506c7d12674307492 Minor docstring fix.
  df54646ab324b11e99279dc0b6dfa161a1c72c7d Fixed the Timeline node.
D 4dcecb97bf4586c26f7e955980caa7e9630ae9a7 More cleaning.
X eda5a993cab01acd6878ab6c982b075d2cba167b *** empty log message ***
C b05bc10e6794c902df679b906d8bd6ec3f5633a9 Cleaned up code.
B 837c81ce51d90427bbcc32b06d84505b1a1e6b2a Use alist instead of a hashtable.
  960449c9e93725f791bd450d3c85fd71339efb09 Cleaned up the buffer.
  bf09955fec57307616926959b31e19af42520db0 Bugfix for `org-archive-subtree'.
  f247d16417f17140a5bd5d03db164cc74191d9c1 Added support for :maxlevel and :skip-e
  bd172412fafaa0386762826677f9929c9c4fc41c Added support for recursive publication
  96e96fa684585e9916f4d6cdde20d4df7ff3f7d7 Added (require 'erc-log).

Thanks for git! Bernt

On Nov 4, 2008, at 11:59 PM, Bernt Hansen wrote:

B,C,X and D are not part of 'F', so why should they be included?

You can do something like 'git log -S... F D' to show commits that are also in D, or git log --all to show all commits.

Hi,

On Tue, 4 Nov 2008, Bernt Hansen wrote:

It is not sufficient for it to be in the patch, it has to be added or deleted in whole. So for example if you had a line

	org-publish-validate-link Hello

and you changed it to

	org-publish-validate-link World

git log -SWorld will find the commit, but git log -Sorg-publish-validate-link will not.

Hth, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

It seems nobody has looked at the actual commits, but Dscho got it 80% right.

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.

Junio C Hamano <gitster@pobox.com> writes:

Now I get it :)

Thanks both of you!

Regards, Bernt

Bernt Hansen <bernt@norang.ca> writes:

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

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Ah I wasn't aware of that.

In this case the function 'org-publish-validate-link' was commented out, and then in a later commit the comments were removed.

I was expecting these commits to be found by git log -S.

Thanks!

Bernt