git log -S doesn't find some commits

git log -S doesn't find some commits

[Bernt Hansen]

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

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

[Pieter de Bie]

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

>                  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

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.

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

[Johannes Schindelin]

Hi,

On Tue, 4 Nov 2008, Bernt Hansen wrote:

> 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.

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

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

[Junio C Hamano]

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

> On Tue, 4 Nov 2008, Bernt Hansen wrote:
>
>> 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.
>
> 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.

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.

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

[Bernt Hansen]

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

> On Tue, 4 Nov 2008, Bernt Hansen wrote:
>
>> 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.
>
> 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.

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

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

[Bernt Hansen]

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

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> On Tue, 4 Nov 2008, Bernt Hansen wrote:
>>
>>> 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.
>>
>> 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.
>
> 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.

Now I get it :)

Thanks both of you!

Regards,
Bernt

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

[Junio C Hamano]

Bernt Hansen <bernt@norang.ca> writes:

> Junio C Hamano <gitster@pobox.com> 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