{"thread":{"id":"26333","subject":"Can't find the revelant commit with git-log","startedAt":"2011-01-25T09:01:47Z","lastAt":"2011-02-10T18:50:35Z","messageCount":30,"participants":["Francis Moreau","René Scharfe","Johannes Sixt","Sverre Rabbelier","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"159848","messageId":"m2ipxd2w78.fsf@gmail.com","threadId":"26333","inReplyTo":null,"subject":"Can't find the revelant commit with git-log","fromName":"Francis Moreau","fromEmail":"francis.moro@gmail.com","sentAt":"2011-01-25T09:01:47Z","receivedAt":"2011-01-25T09:01:47Z","isPatch":false,"sender":{"key":"francis.moro@gmail.com","avatar":null},"body":"Hello,\n\nI'm trying to find out a commit which removed a function inside a file.\n\nThe project is the Linux kernel, and I'm trying to look for changes\nwhich happened between v2.6.27 and v2.6.28. The changes happened in the\nfollowing file: drivers/pci/intel-iommu.c where a function has been\nremoved:\n\n $ git --version\n git version 1.7.4.rc3\n\n $ cd ~/linux-2.6/drivers/pci/\n $ git grep blacklist v2.6.27 -- drivers/pci/intel-iommu.c\n $\n\nNo ouput... hmm, I know it's in... oh maybe the path is incorrect\n\n $ git git grep blacklist v2.6.27 -- intel-iommu.c\n v2.6.27:intel-iommu.c:static int blacklist_iommu(const struct dmi_system_id *id)\n v2.6.27:intel-iommu.c: .callback = blacklist_iommu,\n\nah, so Git failed previously without any comments on the wrong\npath... maybe it should ?\n\nSo at that point I know that in the revision v2.6.27, there's a function\ncalled \"blacklist_iommu\" in drivers/pci/intel-iommu.c\n\nNow take a look if it's still there in v2.6.28:\n\n $ git git grep blacklist v2.6.28 -- intel-iommu.c\n $\n\nThis time nothing is printed but I know that the command is correct.\n\nSo now I'm interested in looking for the commit which removed this\nfunction. Fo this I'm trying to use git-log(1):\n\n $ git log --full-history --follow -S'static int blacklist_iommu(const struct dmi_system_id *id)' v2.6.27..v2.6.28 -- intel-iommu.c\n $ echo $?\n 0\n\nI tried different options but it fails.\n\nAlso I found that passing the exact string to '-S' is annoying, are\nthere any way to just pass a part of the string such as\n\"-Sblacklist_iommu\" ?\n\nSorry if I miss the revelant git-log's option, but there're so many...\n-- \nFrancis\n"},{"id":"159851","messageId":"4D3EF650.20407@lsrfire.ath.cx","threadId":"26333","inReplyTo":"m2ipxd2w78.fsf@gmail.com","subject":"Re: Can't find the revelant commit with git-log","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2011-01-25T16:12:00Z","receivedAt":"2011-01-25T16:12:00Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 25.01.2011 10:01, schrieb Francis Moreau:\n> Hello,\n> \n> I'm trying to find out a commit which removed a function inside a file.\n> \n> The project is the Linux kernel, and I'm trying to look for changes\n> which happened between v2.6.27 and v2.6.28. The changes happened in the\n> following file: drivers/pci/intel-iommu.c where a function has been\n> removed:\n> \n> $ git --version\n> git version 1.7.4.rc3\n> \n> $ cd ~/linux-2.6/drivers/pci/\n> $ git grep blacklist v2.6.27 -- drivers/pci/intel-iommu.c\n> $\n> \n> No ouput... hmm, I know it's in... oh maybe the path is incorrect\n> \n> $ git git grep blacklist v2.6.27 -- intel-iommu.c\n> v2.6.27:intel-iommu.c:static int blacklist_iommu(const struct dmi_system_id *id)\n> v2.6.27:intel-iommu.c: .callback = blacklist_iommu,\n> \n> ah, so Git failed previously without any comments on the wrong\n> path... maybe it should ?\n\nGood idea.\n\n> So at that point I know that in the revision v2.6.27, there's a function\n> called \"blacklist_iommu\" in drivers/pci/intel-iommu.c\n> \n> Now take a look if it's still there in v2.6.28:\n> \n> $ git git grep blacklist v2.6.28 -- intel-iommu.c\n> $\n> \n> This time nothing is printed but I know that the command is correct.\n> \n> So now I'm interested in looking for the commit which removed this\n> function. Fo this I'm trying to use git-log(1):\n> \n> $ git log --full-history --follow -S'static int blacklist_iommu(const struct dmi_system_id *id)' v2.6.27..v2.6.28 -- intel-iommu.c\n> $ echo $?\n> 0\n> \n> I tried different options but it fails.\n> \n> Also I found that passing the exact string to '-S' is annoying, are\n> there any way to just pass a part of the string such as\n> \"-Sblacklist_iommu\" ?\n\nThis (-Sblacklist_iommu) works for me.\n\n> Sorry if I miss the revelant git-log's option, but there're so many...\n\nTry -m (show full diff for merge commits), as the change you're looking\nfor seems to have been introduced by a merge, not a regular commit.\n\n\t$ opts=\"--stat -Sblacklist_iommu -m --oneline\"\n\t$ revs=\"v2.6.27..v2.6.28\"\n\n\t$ git log $opts $revs -- drivers/pci/intel-iommu.c\n\nThis returns nothing. Hmm. Let's try this instead:\n\n\t$ git log $opts $revs -- drivers/pci/\n\t057316c (from 3e2dab9) Merge branch 'linus' into test\n\t drivers/pci/intel-iommu.c | 307 ++++++++++++++++++++------------------------\n\t 1 files changed, 140 insertions(+), 167 deletions(-)\n\t6b2ada8 (from 3b7ecb5) Merge branches 'core/softlockup', 'core/softirq', 'core/resources', 'core/printk' and 'core/misc' into core-v28-for-linus\n\t drivers/pci/intel-iommu.c | 187 ++++++--------------------------------------\n\t 1 files changed, 26 insertions(+), 161 deletions(-)\n\td847059 (from 725c258) Merge branch 'x86/apic' into x86-v28-for-linus-phase4-B\n\t drivers/pci/intel-iommu.c | 185 ++++++---------------------------------------\n\t 1 files changed, 25 insertions(+), 160 deletions(-)\n\t725c258 (from 129d6ab) Merge branches 'core/iommu', 'x86/amd-iommu' and 'x86/iommu' into x86-v28-for-linus-phase3-B\n\t drivers/pci/intel-iommu.c | 25 ++++++++++++++++++++++++-\n\t 1 files changed, 24 insertions(+), 1 deletions(-)\n\t6e03f99 (from 9821626) Merge branch 'linus' into x86/iommu\n\t drivers/pci/intel-iommu.c | 23 +++++++++++++++++++++++\n\t 1 files changed, 23 insertions(+), 0 deletions(-)\n\nStrange, why did we need to remove the last path component to get these\nresults which say that exactly the file we previously specified was changed?\n\nAlso interesting, and matching the above results in that we see the need for\nthe -m flag confirmed:\n\n\t$ for merge in 057316c 6b2ada8 d847059 725c258 6e03f99\n\tdo\n\t\ta=$(git show $merge | grep -c blacklist_iommu)\n\t\tb=$(git show -m $merge | grep -c blacklist_iommu)\n\t\techo $merge $a $b\n\tdone\n\t057316c 0 2\n\t6b2ada8 0 2\n\td847059 0 2\n\t725c258 0 2\n\t6e03f99 0 2\n\nIAW: the combined diff for the five found merges doesn't show any changes to\na line containing the string \"blacklist_iommu\", but the full diffs do.\n\nLet's check for the presence of the string in the merge results and their\nparents:\n\n\t$ for merge in 057316c 6b2ada8 d847059 725c258 6e03f99\n\t do\n\t\tfor rev in $(git show $merge | grep ^Merge:)\n\t\tdo\n\t\t\tt=parent\n\t\t\tcase $rev in\n\t\t\tMerge:)\n\t\t\t\techo\n\t\t\t\trev=$merge\n\t\t\t\tt=merge\n\t\t\t\t;;\n\t\t\tesac\n\t\t\tif git grep -q blacklist_iommu $rev -- drivers/pci/\n\t\t\tthen\n\t\t\t\techo \"$t $rev: found\"\n\t\t\telse\n\t\t\t\techo \"$t $rev: not found\"\n\t\t\tfi\n\t\tdone\n\tdone\n\n\tmerge 057316c: not found\n\tparent 3e2dab9: found\n\tparent 2515ddc: not found\n\t\n\tmerge 6b2ada8: not found\n\tparent 278429c: not found\n\tparent 3b7ecb5: found\n\tparent 77af7e3: not found\n\tparent 1516071: not found\n\tparent 1fa63a8: not found\n\tparent 8546232: not found\n\t\n\tmerge d847059: not found\n\tparent 725c258: found\n\tparent 11494547: not found\n\t\n\tmerge 725c258: found\n\tparent 3dd392a: found\n\tparent 72d3105: found\n\tparent 129d6ab: not found\n\tparent 1e19b16: found\n\t\n\tmerge 6e03f99: found\n\tparent 9821626: not found\n\tparent 6bfb09a: found\n\nHmm, seems like the function is gone since d847059. Does all of this help\nyou in any way?\n\nRené\n"},{"id":"159853","messageId":"m2ipxc27zi.fsf@gmail.com","threadId":"26333","inReplyTo":"4D3EF650.20407@lsrfire.ath.cx","subject":"Re: Can't find the revelant commit with git-log","fromName":"Francis Moreau","fromEmail":"francis.moro@gmail.com","sentAt":"2011-01-25T17:44:49Z","receivedAt":"2011-01-25T17:44:49Z","isPatch":false,"sender":{"key":"francis.moro@gmail.com","avatar":null},"body":"René Scharfe writes:\n\n> Am 25.01.2011 10:01, schrieb Francis Moreau:\n>>\n>> The project is the Linux kernel, and I'm trying to look for changes\n>> which happened between v2.6.27 and v2.6.28. The changes happened in the\n>> following file: drivers/pci/intel-iommu.c where a function has been\n>> removed:\n>> \n>> $ git --version\n>> git version 1.7.4.rc3\n>> \n>> $ cd ~/linux-2.6/drivers/pci/\n>> $ git grep blacklist v2.6.27 -- drivers/pci/intel-iommu.c\n>> $\n>> \n>> No ouput... hmm, I know it's in... oh maybe the path is incorrect\n>> \n>> $ git git grep blacklist v2.6.27 -- intel-iommu.c\n>> v2.6.27:intel-iommu.c:static int blacklist_iommu(const struct dmi_system_id *id)\n>> v2.6.27:intel-iommu.c: .callback = blacklist_iommu,\n>> \n>> ah, so Git failed previously without any comments on the wrong\n>> path... maybe it should ?\n>\n> Good idea.\n>\n\nActually I _think_ I encoutered this behaviour for other commands as well,\nlike git-show or git-log, I don't remember.\n\n>\n>> So at that point I know that in the revision v2.6.27, there's a function\n>> called \"blacklist_iommu\" in drivers/pci/intel-iommu.c\n>> \n>> Now take a look if it's still there in v2.6.28:\n>> \n>> $ git git grep blacklist v2.6.28 -- intel-iommu.c\n>> $\n>> \n>> This time nothing is printed but I know that the command is correct.\n>> \n>> So now I'm interested in looking for the commit which removed this\n>> function. Fo this I'm trying to use git-log(1):\n>> \n>> $ git log --full-history --follow -S'static int blacklist_iommu(const struct dmi_system_id *id)' v2.6.27..v2.6.28 -- intel-iommu.c\n>> $ echo $?\n>> 0\n>> \n>> I tried different options but it fails.\n>> \n>> Also I found that passing the exact string to '-S' is annoying, are\n>> there any way to just pass a part of the string such as\n>> \"-Sblacklist_iommu\" ?\n>\n> This (-Sblacklist_iommu) works for me.\n>\n\nHmm, I thought I tried this and it didn't work, but that's obviously\nwrong.\n\n>\n>> Sorry if I miss the revelant git-log's option, but there're so many...\n>\n> Try -m (show full diff for merge commits), as the change you're looking\n> for seems to have been introduced by a merge, not a regular commit.\n>\n> \t$ opts=\"--stat -Sblacklist_iommu -m --oneline\"\n> \t$ revs=\"v2.6.27..v2.6.28\"\n>\n> \t$ git log $opts $revs -- drivers/pci/intel-iommu.c\n>\n> This returns nothing. Hmm. Let's try this instead:\n>\n> \t$ git log $opts $revs -- drivers/pci/\n> \t057316c (from 3e2dab9) Merge branch 'linus' into test\n> \t drivers/pci/intel-iommu.c | 307 ++++++++++++++++++++------------------------\n> \t 1 files changed, 140 insertions(+), 167 deletions(-)\n> \t6b2ada8 (from 3b7ecb5) Merge branches 'core/softlockup', 'core/softirq', 'core/resources', 'core/printk' and 'core/misc' into core-v28-for-linus\n> \t drivers/pci/intel-iommu.c | 187 ++++++--------------------------------------\n> \t 1 files changed, 26 insertions(+), 161 deletions(-)\n> \td847059 (from 725c258) Merge branch 'x86/apic' into x86-v28-for-linus-phase4-B\n> \t drivers/pci/intel-iommu.c | 185 ++++++---------------------------------------\n> \t 1 files changed, 25 insertions(+), 160 deletions(-)\n> \t725c258 (from 129d6ab) Merge branches 'core/iommu', 'x86/amd-iommu' and 'x86/iommu' into x86-v28-for-linus-phase3-B\n> \t drivers/pci/intel-iommu.c | 25 ++++++++++++++++++++++++-\n> \t 1 files changed, 24 insertions(+), 1 deletions(-)\n> \t6e03f99 (from 9821626) Merge branch 'linus' into x86/iommu\n> \t drivers/pci/intel-iommu.c | 23 +++++++++++++++++++++++\n> \t 1 files changed, 23 insertions(+), 0 deletions(-)\n>\n> Strange, why did we need to remove the last path component to get these\n> results which say that exactly the file we previously specified was changed?\n\nah... I think I've been hit by this, since I tried '-m' too but see\nnothing and was not smart enough to remove the filename from the path.\n\n> Also interesting, and matching the above results in that we see the need for\n> the -m flag confirmed:\n>\n> \t$ for merge in 057316c 6b2ada8 d847059 725c258 6e03f99\n> \tdo\n> \t\ta=$(git show $merge | grep -c blacklist_iommu)\n> \t\tb=$(git show -m $merge | grep -c blacklist_iommu)\n> \t\techo $merge $a $b\n> \tdone\n> \t057316c 0 2\n> \t6b2ada8 0 2\n> \td847059 0 2\n> \t725c258 0 2\n> \t6e03f99 0 2\n>\n> IAW: the combined diff for the five found merges doesn't show any changes to\n> a line containing the string \"blacklist_iommu\", but the full diffs do.\n>\n> Let's check for the presence of the string in the merge results and their\n> parents:\n>\n> \t$ for merge in 057316c 6b2ada8 d847059 725c258 6e03f99\n> \t do\n> \t\tfor rev in $(git show $merge | grep ^Merge:)\n> \t\tdo\n> \t\t\tt=parent\n> \t\t\tcase $rev in\n> \t\t\tMerge:)\n> \t\t\t\techo\n> \t\t\t\trev=$merge\n> \t\t\t\tt=merge\n> \t\t\t\t;;\n> \t\t\tesac\n> \t\t\tif git grep -q blacklist_iommu $rev -- drivers/pci/\n> \t\t\tthen\n> \t\t\t\techo \"$t $rev: found\"\n> \t\t\telse\n> \t\t\t\techo \"$t $rev: not found\"\n> \t\t\tfi\n> \t\tdone\n> \tdone\n>\n> \tmerge 057316c: not found\n> \tparent 3e2dab9: found\n> \tparent 2515ddc: not found\n> \t\n> \tmerge 6b2ada8: not found\n> \tparent 278429c: not found\n> \tparent 3b7ecb5: found\n> \tparent 77af7e3: not found\n> \tparent 1516071: not found\n> \tparent 1fa63a8: not found\n> \tparent 8546232: not found\n> \t\n> \tmerge d847059: not found\n> \tparent 725c258: found\n> \tparent 11494547: not found\n> \t\n> \tmerge 725c258: found\n> \tparent 3dd392a: found\n> \tparent 72d3105: found\n> \tparent 129d6ab: not found\n> \tparent 1e19b16: found\n> \t\n> \tmerge 6e03f99: found\n> \tparent 9821626: not found\n> \tparent 6bfb09a: found\n>\n> Hmm, seems like the function is gone since d847059. Does all of this help\n> you in any way?\n\nYes it does, but one question I'm wondering is: is it possible to do\nthis more user friendly ? ;)\n\nThanks\n-- \nFrancis\n"},{"id":"159878","messageId":"m239og12pe.fsf@gmail.com","threadId":"26333","inReplyTo":"m2ipxc27zi.fsf@gmail.com","subject":"Re: Can't find the revelant commit with git-log","fromName":"Francis Moreau","fromEmail":"francis.moro@gmail.com","sentAt":"2011-01-26T08:36:29Z","receivedAt":"2011-01-26T08:36:29Z","isPatch":false,"sender":{"key":"francis.moro@gmail.com","avatar":null},"body":"Francis Moreau writes:\n\n> René Scharfe writes:\n>\n>> Am 25.01.2011 10:01, schrieb Francis Moreau:\n>>>\n>>> The project is the Linux kernel, and I'm trying to look for changes\n>>> which happened between v2.6.27 and v2.6.28. The changes happened in the\n>>> following file: drivers/pci/intel-iommu.c where a function has been\n>>> removed:\n>>> \n>>> $ git --version\n>>> git version 1.7.4.rc3\n>>> \n>>> $ cd ~/linux-2.6/drivers/pci/\n>>> $ git grep blacklist v2.6.27 -- drivers/pci/intel-iommu.c\n>>> $\n>>> \n>>> No ouput... hmm, I know it's in... oh maybe the path is incorrect\n>>> \n>>> $ git git grep blacklist v2.6.27 -- intel-iommu.c\n>>> v2.6.27:intel-iommu.c:static int blacklist_iommu(const struct dmi_system_id *id)\n>>> v2.6.27:intel-iommu.c: .callback = blacklist_iommu,\n>>> \n>>> ah, so Git failed previously without any comments on the wrong\n>>> path... maybe it should ?\n>>\n>> Good idea.\n>>\n>\n> Actually I _think_ I encoutered this behaviour for other commands as well,\n> like git-show or git-log, I don't remember.\n>\n>>\n>>> So at that point I know that in the revision v2.6.27, there's a function\n>>> called \"blacklist_iommu\" in drivers/pci/intel-iommu.c\n>>> \n>>> Now take a look if it's still there in v2.6.28:\n>>> \n>>> $ git git grep blacklist v2.6.28 -- intel-iommu.c\n>>> $\n>>> \n>>> This time nothing is printed but I know that the command is correct.\n>>> \n>>> So now I'm interested in looking for the commit which removed this\n>>> function. Fo this I'm trying to use git-log(1):\n>>> \n>>> $ git log --full-history --follow -S'static int blacklist_iommu(const struct dmi_system_id *id)' v2.6.27..v2.6.28 -- intel-iommu.c\n>>> $ echo $?\n>>> 0\n>>> \n>>> I tried different options but it fails.\n>>> \n>>> Also I found that passing the exact string to '-S' is annoying, are\n>>> there any way to just pass a part of the string such as\n>>> \"-Sblacklist_iommu\" ?\n>>\n>> This (-Sblacklist_iommu) works for me.\n>>\n>\n> Hmm, I thought I tried this and it didn't work, but that's obviously\n> wrong.\n>\n>>\n>>> Sorry if I miss the revelant git-log's option, but there're so many...\n>>\n>> Try -m (show full diff for merge commits), as the change you're looking\n>> for seems to have been introduced by a merge, not a regular commit.\n>>\n>> \t$ opts=\"--stat -Sblacklist_iommu -m --oneline\"\n>> \t$ revs=\"v2.6.27..v2.6.28\"\n>>\n>> \t$ git log $opts $revs -- drivers/pci/intel-iommu.c\n>>\n>> This returns nothing. Hmm. Let's try this instead:\n>>\n>> \t$ git log $opts $revs -- drivers/pci/\n>> \t057316c (from 3e2dab9) Merge branch 'linus' into test\n>> \t drivers/pci/intel-iommu.c | 307 ++++++++++++++++++++------------------------\n>> \t 1 files changed, 140 insertions(+), 167 deletions(-)\n>> \t6b2ada8 (from 3b7ecb5) Merge branches 'core/softlockup', 'core/softirq', 'core/resources', 'core/printk' and 'core/misc' into core-v28-for-linus\n>> \t drivers/pci/intel-iommu.c | 187 ++++++--------------------------------------\n>> \t 1 files changed, 26 insertions(+), 161 deletions(-)\n>> \td847059 (from 725c258) Merge branch 'x86/apic' into x86-v28-for-linus-phase4-B\n>> \t drivers/pci/intel-iommu.c | 185 ++++++---------------------------------------\n>> \t 1 files changed, 25 insertions(+), 160 deletions(-)\n>> \t725c258 (from 129d6ab) Merge branches 'core/iommu', 'x86/amd-iommu' and 'x86/iommu' into x86-v28-for-linus-phase3-B\n>> \t drivers/pci/intel-iommu.c | 25 ++++++++++++++++++++++++-\n>> \t 1 files changed, 24 insertions(+), 1 deletions(-)\n>> \t6e03f99 (from 9821626) Merge branch 'linus' into x86/iommu\n>> \t drivers/pci/intel-iommu.c | 23 +++++++++++++++++++++++\n>> \t 1 files changed, 23 insertions(+), 0 deletions(-)\n>>\n>> Strange, why did we need to remove the last path component to get these\n>> results which say that exactly the file we previously specified was changed?\n>\n> ah... I think I've been hit by this, since I tried '-m' too but see\n> nothing and was not smart enough to remove the filename from the path.\n>\n>> Also interesting, and matching the above results in that we see the need for\n>> the -m flag confirmed:\n\nBTW, couldn't '-m' automatically set when '-S' is given ?\n\n>> \n>>\n>> \t$ for merge in 057316c 6b2ada8 d847059 725c258 6e03f99\n>> \tdo\n>> \t\ta=$(git show $merge | grep -c blacklist_iommu)\n>> \t\tb=$(git show -m $merge | grep -c blacklist_iommu)\n>> \t\techo $merge $a $b\n>> \tdone\n>> \t057316c 0 2\n>> \t6b2ada8 0 2\n>> \td847059 0 2\n>> \t725c258 0 2\n>> \t6e03f99 0 2\n>>\n>> IAW: the combined diff for the five found merges doesn't show any changes to\n>> a line containing the string \"blacklist_iommu\", but the full diffs do.\n>>\n>> Let's check for the presence of the string in the merge results and their\n>> parents:\n>>\n>> \t$ for merge in 057316c 6b2ada8 d847059 725c258 6e03f99\n>> \t do\n>> \t\tfor rev in $(git show $merge | grep ^Merge:)\n>> \t\tdo\n>> \t\t\tt=parent\n>> \t\t\tcase $rev in\n>> \t\t\tMerge:)\n>> \t\t\t\techo\n>> \t\t\t\trev=$merge\n>> \t\t\t\tt=merge\n>> \t\t\t\t;;\n>> \t\t\tesac\n>> \t\t\tif git grep -q blacklist_iommu $rev -- drivers/pci/\n>> \t\t\tthen\n>> \t\t\t\techo \"$t $rev: found\"\n>> \t\t\telse\n>> \t\t\t\techo \"$t $rev: not found\"\n>> \t\t\tfi\n>> \t\tdone\n>> \tdone\n>>\n>> \tmerge 057316c: not found\n>> \tparent 3e2dab9: found\n>> \tparent 2515ddc: not found\n>> \t\n>> \tmerge 6b2ada8: not found\n>> \tparent 278429c: not found\n>> \tparent 3b7ecb5: found\n>> \tparent 77af7e3: not found\n>> \tparent 1516071: not found\n>> \tparent 1fa63a8: not found\n>> \tparent 8546232: not found\n>> \t\n>> \tmerge d847059: not found\n>> \tparent 725c258: found\n>> \tparent 11494547: not found\n>> \t\n>> \tmerge 725c258: found\n>> \tparent 3dd392a: found\n>> \tparent 72d3105: found\n>> \tparent 129d6ab: not found\n>> \tparent 1e19b16: found\n>> \t\n>> \tmerge 6e03f99: found\n>> \tparent 9821626: not found\n>> \tparent 6bfb09a: found\n>>\n>> Hmm, seems like the function is gone since d847059. Does all of this help\n>> you in any way?\n>\n> Yes it does, but one question I'm wondering is: is it possible to do\n> this more user friendly ? ;)\n\nI tried to reproduce something similar but with a far more simple repo:\n\n\n 1.f o\n |\n 1.e o (merge)\n | \\\n 1.d o o 2.c (merge)\n | | \\\n 1.c o o o 3.a \"Remove blacklist_iommu()\"\n | | /\n | o 2.a\n | /\n 1.b o\n |\n 1.a o \"Introduce blacklist_iommu()\"\n |\n o Init\n\nBasically this repo 3 branches: master, 2, 3. Master branch introduces\nthe \"blacklist_iommu()\" function with commit 1.a, and branch \"3\" removes\nit at commit 3.a.\n\nSo now:\n\n $ git log --oneline -S\"blacklist_iommu\"\n ea1ddb0 3.a\n 8053460 1.a\n\n\n $ git show :/3.a\n commit ea1ddb023833470be173363a71a3a055ae8acb85\n Author: Francis Moreau \n Date: Wed Jan 26 09:17:58 2011 +0100\n \n 3.a\n \n Remove blacklist_iommy()\n \n diff --git a/intel-iommu.c b/intel-iommu.c\n index 2c9539d..f19c1cc 100644\n --- a/intel-iommu.c\n +++ b/intel-iommu.c\n @@ -2,12 +2,4 @@ Wed Jan 26 09:10:15 CET 2011\n Wed Jan 26 09:16:23 CET 2011\n \n \n -static int blacklist_iommu(const struct dmi_system_id *id)\n -{\n - printk(KERN_INFO \"%s detected; disabling IOMMU\\n\",\n -\t id->ident);\n - dmar_disabled = 1;\n - return 0;\n -}\n -\n Wed Jan 26 09:14:40 CET 2011\n\nSo in this case there's no need to pass the '-m' flag and git-log(1), by\ndefault walks through all the commits:\n\n $ git log --oneline v2.6.27..v2.6.28\n e2a5af3 1.e\n c9fbd3a Merge branch '2'\n a8207d9 Merge branch '3' into 2\n ea1ddb0 3.a\n 3a86ada 2.b\n 767186a 2.a\n 45beaac 1.d\n 1af781c 1.c\n 4f9b5c1 1.b\n 8053460 1.a\n\nwhereas in my previous example, it doesn't seem to be true.\n\nCould you shed some light ?\n\nThanks\n-- \nFrancis\n"},{"id":"159879","messageId":"m2y668yr6k.fsf@gmail.com","threadId":"26333","inReplyTo":"4D3EF650.20407@lsrfire.ath.cx","subject":"Re: Can't find the revelant commit with git-log","fromName":"Francis Moreau","fromEmail":"francis.moro@gmail.com","sentAt":"2011-01-26T09:01:23Z","receivedAt":"2011-01-26T09:01:23Z","isPatch":false,"sender":{"key":"francis.moro@gmail.com","avatar":null},"body":"René Scharfe writes:\n\n[...]\n\n> Hmm, seems like the function is gone since d847059. Does all of this help\n> you in any way?\n\nSigh... one more try, one more failure...\n\nThis time I tried to use git-bisect(1) to see if I couldn't track the\nchange more easily.\n\nSo, here's what I did:\n\n $ cat ./bisect.sh\n #! /bin/sh\n \n if ! git grep -q -e blacklist_iommu -- drivers/pci/intel-iommu.c\n then\n \texit 1\n fi\n\n $ git bisect start v2.6.28 v2.6.27 -- drivers/pci\n Bisecting: 70 revisions left to test after this (roughly 6 steps)\n [a0bfb673dca8a2b4324fe11e678ec6d6a9ad67e0] Merge branch 'linux-next' of\n git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6\n\n $ git bisect run ./bisect.sh \n running /dev/shm/bisect.sh\n Bisecting: 42 revisions left to test after this (roughly 5 steps)\n [0235c4fc7fc6f621dc0dd89eba102ad5aa373390] PCI PM: Introduce function\n pci_wake_from_d3\n running /dev/shm/bisect.sh\n error: The following untracked working tree files would be overwritten\n by checkout:\n arch/x86/es7000/Makefile\n arch/x86/es7000/es7000.h\n arch/x86/es7000/es7000plat.c\n drivers/pci/dma_remapping.h\n Please move or remove them before you can switch branches.\n Bisecting: 18 revisions left to test after this (roughly 4 steps)\n Aborting\n bisect run failed:\n 'bisect_state bad' exited with error code 1\n\nDo you know what's going wrong ?\n\nThanks\n-- \nFrancis\n"},{"id":"159887","messageId":"4D3FFB0F.9070700@viscovery.net","threadId":"26333","inReplyTo":"m239og12pe.fsf@gmail.com","subject":"Re: Can't find the revelant commit with git-log","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2011-01-26T10:44:31Z","receivedAt":"2011-01-26T10:44:31Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Please don't set Mail-Followup-To; it's disliked on this list.\n\nAm 1/26/2011 9:36, schrieb Francis Moreau:\n> I tried to reproduce something similar but with a far more simple repo:\n> \n> \n> 1.f o\n> |\n> 1.e o (merge)\n> | \\\n> 1.d o o 2.c (merge)\n> | | \\\n> 1.c o o o 3.a \"Remove blacklist_iommu()\"\n> | | /\n> | o 2.a\n> | /\n> 1.b o\n> |\n> 1.a o \"Introduce blacklist_iommu()\"\n> |\n> o Init\n> \n> Basically this repo 3 branches: master, 2, 3. Master branch introduces\n> the \"blacklist_iommu()\" function with commit 1.a, and branch \"3\" removes\n> it at commit 3.a.\n> ...\n> So in this case there's no need to pass the '-m' flag and git-log(1), by\n> default walks through all the commits:\n\nTo reproduce the real history, you have to modify your example in three ways:\n\n1. 2.a must be forked off of Init, not 1.b; i.e., this commit does not\ncontain \"blacklist_iommu\".\n\n2. Drop the side branch that removes the word. (Drop at least the commit.)\n\n3. The merge 1.e (which resembles d847059) must be modified such that it\ntakes the contents of 2.c rather than 1.d.\n\nIOW, \"blacklist_iommu\" is not removed explicitly by a commit, but rather\nby a merge of one branch that has it and another one that doesn't have it.\n\nLook closely at d847059: The commit message hints at a conflict in\nintel_iommu.c, and Ingo resolved the conflict by taking the contents of\nthe file of one branch, namely the branch that does *not* contain\n\"blacklist_iommu\", ignoring entirely what happend on the other branch\n(that had added \"blacklist_iommu\" somewhere at or before v2.6.27).\n\n-- Hannes\n"},{"id":"159897","messageId":"4D4063EC.7090509@lsrfire.ath.cx","threadId":"26333","inReplyTo":"m239og12pe.fsf@gmail.com","subject":"Re: Can't find the revelant commit with git-log","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2011-01-26T18:11:56Z","receivedAt":"2011-01-26T18:11:56Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 26.01.2011 09:36, schrieb Francis Moreau:\n> Francis Moreau writes:\n> \n>> René Scharfe writes:\n>>\n>>> Try -m (show full diff for merge commits), as the change you're looking\n>>> for seems to have been introduced by a merge, not a regular commit.\n>>>\n>>> \t$ opts=\"--stat -Sblacklist_iommu -m --oneline\"\n>>> \t$ revs=\"v2.6.27..v2.6.28\"\n>>>\n>>> \t$ git log $opts $revs -- drivers/pci/intel-iommu.c\n>>>\n>>> This returns nothing. Hmm. Let's try this instead:\n>>>\n>>> \t$ git log $opts $revs -- drivers/pci/\n>>> \t057316c (from 3e2dab9) Merge branch 'linus' into test\n>>> \t drivers/pci/intel-iommu.c | 307 ++++++++++++++++++++------------------------\n>>> \t 1 files changed, 140 insertions(+), 167 deletions(-)\n>>> \t6b2ada8 (from 3b7ecb5) Merge branches 'core/softlockup', 'core/softirq', 'core/resources', 'core/printk' and 'core/misc' into core-v28-for-linus\n>>> \t drivers/pci/intel-iommu.c | 187 ++++++--------------------------------------\n>>> \t 1 files changed, 26 insertions(+), 161 deletions(-)\n>>> \td847059 (from 725c258) Merge branch 'x86/apic' into x86-v28-for-linus-phase4-B\n>>> \t drivers/pci/intel-iommu.c | 185 ++++++---------------------------------------\n>>> \t 1 files changed, 25 insertions(+), 160 deletions(-)\n>>> \t725c258 (from 129d6ab) Merge branches 'core/iommu', 'x86/amd-iommu' and 'x86/iommu' into x86-v28-for-linus-phase3-B\n>>> \t drivers/pci/intel-iommu.c | 25 ++++++++++++++++++++++++-\n>>> \t 1 files changed, 24 insertions(+), 1 deletions(-)\n>>> \t6e03f99 (from 9821626) Merge branch 'linus' into x86/iommu\n>>> \t drivers/pci/intel-iommu.c | 23 +++++++++++++++++++++++\n>>> \t 1 files changed, 23 insertions(+), 0 deletions(-)\n>>>\n>>> Strange, why did we need to remove the last path component to get these\n>>> results which say that exactly the file we previously specified was changed?\n>>\n>> ah... I think I've been hit by this, since I tried '-m' too but see\n>> nothing and was not smart enough to remove the filename from the path.\n>>\n>>> Also interesting, and matching the above results in that we see the need for\n>>> the -m flag confirmed:\n> \n> BTW, couldn't '-m' automatically set when '-S' is given ?\n\nI can't see a connection between the two options. Merges are ignored by\ndefault (without -m) because they shouldn't contain any changes that\naren't already present in one of the merged branches (by convention),\nand diffs with a single parent are easier to read. This is true with or\nwithout -S.\n\nSo far we have two action items, I think:\n\n\t- Make git grep report non-matching path specs (new feature).\n\n\t- Find out why removing the last path component made a\n\t difference in the case above (looks like a bug, but I don't\n\t understand what's going on).\n\nTaking into account what Johannes said regarding the disappearance of\nthe function during a merge instead of as part of a regular commit, I\ndon't think these changes would help you much with your use case,\nthough. You would still be looking at a complicated net of commits,\nwith the action happening in non-obvious places (merges).\n\nPerhaps --graph can help a bit, see for yourself:\n\n\t$ git log --graph -Sblacklist_iommu -m --oneline \\\n\tv2.6.27..v2.6.28 -- drivers/pci/\n\nIf you start at v.2.6.26 instead -- e.g. to catch the commit that\nintroduced the function -- then the graph gets a lot more colourful and\ntoo complicated, at least for me, though.\n\nRené\n"},{"id":"159899","messageId":"4D406A64.1000200@lsrfire.ath.cx","threadId":"26333","inReplyTo":"m2y668yr6k.fsf@gmail.com","subject":"Re: Can't find the revelant commit with git-log","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2011-01-26T18:39:32Z","receivedAt":"2011-01-26T18:39:32Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 26.01.2011 10:01, schrieb Francis Moreau:\n> René Scharfe writes:\n> \n> [...]\n> \n>> Hmm, seems like the function is gone since d847059. Does all of this help\n>> you in any way?\n> \n> Sigh... one more try, one more failure...\n> \n> This time I tried to use git-bisect(1) to see if I couldn't track the\n> change more easily.\n> \n> So, here's what I did:\n> \n> $ cat ./bisect.sh\n> #! /bin/sh\n> \n> if ! git grep -q -e blacklist_iommu -- drivers/pci/intel-iommu.c\n> then\n> \texit 1\n> fi\n> \n> $ git bisect start v2.6.28 v2.6.27 -- drivers/pci\n> Bisecting: 70 revisions left to test after this (roughly 6 steps)\n> [a0bfb673dca8a2b4324fe11e678ec6d6a9ad67e0] Merge branch 'linux-next' of\n> git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6\n> \n> $ git bisect run ./bisect.sh \n> running /dev/shm/bisect.sh\n> Bisecting: 42 revisions left to test after this (roughly 5 steps)\n> [0235c4fc7fc6f621dc0dd89eba102ad5aa373390] PCI PM: Introduce function\n> pci_wake_from_d3\n> running /dev/shm/bisect.sh\n> error: The following untracked working tree files would be overwritten\n> by checkout:\n> arch/x86/es7000/Makefile\n> arch/x86/es7000/es7000.h\n> arch/x86/es7000/es7000plat.c\n> drivers/pci/dma_remapping.h\n> Please move or remove them before you can switch branches.\n\nThese are untracked files; your tree is not clean. Either commit them,\nstash them away or delete the files. Or make a local clone just for\nbisecting purposes.\n\n> Bisecting: 18 revisions left to test after this (roughly 4 steps)\n> Aborting\n> bisect run failed:\n> 'bisect_state bad' exited with error code 1\n> \n> Do you know what's going wrong ?\n\nI tried the same and the result was:\n\n\te61d98d8dad0048619bb138b0ff996422ffae53b is the first bad commit\n\nBut this probably won't help you much, either, as it is a regular commit\nwhich doesn't touch the function (it doesn't exist before and after it).\n\nI can only guess that bisect gets confused by the merges just like log\n(and me).\n\nRené\n"},{"id":"159904","messageId":"m2lj27zbp5.fsf@gmail.com","threadId":"26333","inReplyTo":"4D406A64.1000200@lsrfire.ath.cx","subject":"Re: Can't find the revelant commit with git-log","fromName":"Francis Moreau","fromEmail":"francis.moro@gmail.com","sentAt":"2011-01-26T19:50:30Z","receivedAt":"2011-01-26T19:50:30Z","isPatch":false,"sender":{"key":"francis.moro@gmail.com","avatar":null},"body":"René Scharfe writes:\n\n> Am 26.01.2011 10:01, schrieb Francis Moreau:\n\n[...]\n\n>> error: The following untracked working tree files would be overwritten\n>> by checkout:\n>> arch/x86/es7000/Makefile\n>> arch/x86/es7000/es7000.h\n>> arch/x86/es7000/es7000plat.c\n>> drivers/pci/dma_remapping.h\n>> Please move or remove them before you can switch branches.\n>\n> These are untracked files; your tree is not clean. Either commit them,\n> stash them away or delete the files. Or make a local clone just for\n> bisecting purposes.\n>\n\nHmm, I'm wondering how those files get there...\n\nMaybe they are some left from some git commands which failed, I dunno.\n\n-- \nFrancis\n"},{"id":"159913","messageId":"m2hbcvz8me.fsf@gmail.com","threadId":"26333","inReplyTo":"4D3FFB0F.9070700@viscovery.net","subject":"Re: Can't find the revelant commit with git-log","fromName":"Francis Moreau","fromEmail":"francis.moro@gmail.com","sentAt":"2011-01-26T20:56:57Z","receivedAt":"2011-01-26T20:56:57Z","isPatch":false,"sender":{"key":"francis.moro@gmail.com","avatar":null},"body":"Johannes Sixt writes:\n\n> Please don't set Mail-Followup-To; it's disliked on this list.\n\nJust out of curiosity, I'd like to know why, since it has no annoyance\nfor those who are replying to my emails.\n\n>\n>\n> Am 1/26/2011 9:36, schrieb Francis Moreau:\n>> I tried to reproduce something similar but with a far more simple repo:\n>> \n>> \n>> 1.f o\n>> |\n>> 1.e o (merge)\n>> | \\\n>> 1.d o o 2.c (merge)\n>> | | \\\n>> 1.c o o o 3.a \"Remove blacklist_iommu()\"\n>> | | /\n>> | o 2.a\n>> | /\n>> 1.b o\n>> |\n>> 1.a o \"Introduce blacklist_iommu()\"\n>> |\n>> o Init\n>> \n>> Basically this repo 3 branches: master, 2, 3. Master branch introduces\n>> the \"blacklist_iommu()\" function with commit 1.a, and branch \"3\" removes\n>> it at commit 3.a.\n>> ...\n>> So in this case there's no need to pass the '-m' flag and git-log(1), by\n>> default walks through all the commits:\n>\n> To reproduce the real history, you have to modify your example in three ways:\n>\n> 1. 2.a must be forked off of Init, not 1.b; i.e., this commit does not\n> contain \"blacklist_iommu\".\n>\n> 2. Drop the side branch that removes the word. (Drop at least the commit.)\n>\n> 3. The merge 1.e (which resembles d847059) must be modified such that it\n> takes the contents of 2.c rather than 1.d.\n>\n> IOW, \"blacklist_iommu\" is not removed explicitly by a commit, but rather\n> by a merge of one branch that has it and another one that doesn't have it.\n>\n> Look closely at d847059: The commit message hints at a conflict in\n> intel_iommu.c,\n\nBut how did you find out d847059 ?\n\nDid you use René's method ?\n\nThanks\n-- \nFrancis\n"},{"id":"159915","messageId":"AANLkTinKZfkK0uuyNJZf7f1hvfu5-LeSsxaE9fkQ2O5X@mail.gmail.com","threadId":"26333","inReplyTo":"m2hbcvz8me.fsf@gmail.com","subject":"Re: Can't find the revelant commit with git-log","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-01-26T21:03:22Z","receivedAt":"2011-01-26T21:03:22Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Wed, Jan 26, 2011 at 21:56, Francis Moreau wrote:\n> Just out of curiosity, I'd like to know why, since it has no annoyance\n> for those who are replying to my emails.\n\nWe keep everybody on CC who's interested in the thread here, and\nusually reply directly to the person whose email we respond to. In\nthis case, I had to manually edit the TO line to be just you, and move\neverybody else to the CC.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"159916","messageId":"m2d3njz839.fsf@gmail.com","threadId":"26333","inReplyTo":"AANLkTinKZfkK0uuyNJZf7f1hvfu5-LeSsxaE9fkQ2O5X@mail.gmail.com","subject":"Re: Can't find the revelant commit with git-log","fromName":"Francis Moreau","fromEmail":"francis.moro@gmail.com","sentAt":"2011-01-26T21:08:26Z","receivedAt":"2011-01-26T21:08:26Z","isPatch":false,"sender":{"key":"francis.moro@gmail.com","avatar":null},"body":"Sverre Rabbelier writes:\n\n> Heya,\n>\n> On Wed, Jan 26, 2011 at 21:56, Francis Moreau wrote:\n>> Just out of curiosity, I'd like to know why, since it has no annoyance\n>> for those who are replying to my emails.\n>\n> We keep everybody on CC who's interested in the thread here, and\n> usually reply directly to the person whose email we respond to. In\n> this case, I had to manually edit the TO line to be just you, and move\n> everybody else to the CC.\n\nWell, if I decided to set Mail-Followup-To, that do mean that I don't\nwant you to do that !\n\n-- \nFrancis\n"},{"id":"159917","messageId":"AANLkTimzUFL0ByGcA1QRNL+br57ZY6OME4aFAT+ipaJV@mail.gmail.com","threadId":"26333","inReplyTo":"m2d3njz839.fsf@gmail.com","subject":"Re: Can't find the revelant commit with git-log","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-01-26T21:14:37Z","receivedAt":"2011-01-26T21:14:37Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Wed, Jan 26, 2011 at 22:08, Francis Moreau wrote:\n> Well, if I decided to set Mail-Followup-To, that do mean that I don't\n> want you to do that !\n\nYes, but it makes it harder for us to do that. For example, now I had\nto remove myself from the to line, add you, and move everybody else to\nCC. In other words, please don't do it. Thanks :)\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"159918","messageId":"7vei7zjr3y.fsf@alter.siamese.dyndns.org","threadId":"26333","inReplyTo":"m2d3njz839.fsf@gmail.com","subject":"Re: Can't find the revelant commit with git-log","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-01-26T21:24:17Z","receivedAt":"2011-01-26T21:24:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Francis Moreau writes:\n\n>> On Wed, Jan 26, 2011 at 21:56, Francis Moreau wrote:\n>>> Just out of curiosity, I'd like to know why, since it has no annoyance\n>>> for those who are replying to my emails.\n>>\n>> We keep everybody on CC who's interested in the thread here, and\n>> usually reply directly to the person whose email we respond to. In\n>> this case, I had to manually edit the TO line to be just you, and move\n>> everybody else to the CC.\n>\n> Well, if I decided to set Mail-Followup-To, that do mean that I don't\n> want you to do that !\n\nThat is _not_ something for _you_ to unilaterally decide.\n\nI am responding to _you_ with this message to tell _you_ something, while\nkeeping Sverre, J6t and Rene and the list in the loop.\n\nIf I followedyour M-F-T on the message I am responding to, I would have\nended up placing these \"secondary\" (for the purpose of my message) on my\n\"To:\" line. That would make it impossible for them to prioritize the\nmessages addressed directly to them (which would have their address on\n\"To:\") over other messages that they are merely in the loop (which would\nnot have them on \"To:\"---their address may be on \"Cc:\" or they may be\ngetting the message from the list).\n\nSo please don't.\n\nThanks.\n"},{"id":"159919","messageId":"m262tbz70e.fsf@gmail.com","threadId":"26333","inReplyTo":"AANLkTimzUFL0ByGcA1QRNL+br57ZY6OME4aFAT+ipaJV@mail.gmail.com","subject":"Re: Can't find the revelant commit with git-log","fromName":"Francis Moreau","fromEmail":"francis.moro@gmail.com","sentAt":"2011-01-26T21:31:45Z","receivedAt":"2011-01-26T21:31:45Z","isPatch":false,"sender":{"key":"francis.moro@gmail.com","avatar":null},"body":"Sverre Rabbelier writes:\n\n> Heya,\n>\n> On Wed, Jan 26, 2011 at 22:08, Francis Moreau wrote:\n>> Well, if I decided to set Mail-Followup-To, that do mean that I don't\n>> want you to do that !\n>\n> Yes, but it makes it harder for us to do that. For example, now I had\n> to remove myself from the to line, add you, and move everybody else to\n> CC. In other words, please don't do it. Thanks :)\n\nIt should be fixed by now, please let me know it isn't !\n\nI didn't know it works like this: I thought it was set so replies just\nreplace my email address with the mailing list one.\n\nThanks\n-- \nFrancis\n"},{"id":"159920","messageId":"m21v3zz6ze.fsf@gmail.com","threadId":"26333","inReplyTo":"7vei7zjr3y.fsf@alter.siamese.dyndns.org","subject":"Re: Can't find the revelant commit with git-log","fromName":"Francis Moreau","fromEmail":"francis.moro@gmail.com","sentAt":"2011-01-26T21:32:21Z","receivedAt":"2011-01-26T21:32:21Z","isPatch":false,"sender":{"key":"francis.moro@gmail.com","avatar":null},"body":"Junio C Hamano writes:\n\n> Francis Moreau writes:\n>\n>>> On Wed, Jan 26, 2011 at 21:56, Francis Moreau wrote:\n>>>> Just out of curiosity, I'd like to know why, since it has no annoyance\n>>>> for those who are replying to my emails.\n>>>\n>>> We keep everybody on CC who's interested in the thread here, and\n>>> usually reply directly to the person whose email we respond to. In\n>>> this case, I had to manually edit the TO line to be just you, and move\n>>> everybody else to the CC.\n>>\n>> Well, if I decided to set Mail-Followup-To, that do mean that I don't\n>> want you to do that !\n>\n> That is _not_ something for _you_ to unilaterally decide.\n>\n> I am responding to _you_ with this message to tell _you_ something, while\n> keeping Sverre, J6t and Rene and the list in the loop.\n>\n> If I followedyour M-F-T on the message I am responding to, I would have\n> ended up placing these \"secondary\" (for the purpose of my message) on my\n> \"To:\" line. That would make it impossible for them to prioritize the\n> messages addressed directly to them (which would have their address on\n> \"To:\") over other messages that they are merely in the loop (which would\n> not have them on \"To:\"---their address may be on \"Cc:\" or they may be\n> getting the message from the list).\n>\n> So please don't.\n\nAgreed.\n\nShould be fixed now, if not, please let me know.\n\nThanks\n-- \nFrancis\n"},{"id":"160006","messageId":"4D432735.8000208@lsrfire.ath.cx","threadId":"26333","inReplyTo":"4D4063EC.7090509@lsrfire.ath.cx","subject":"Re: Can't find the revelant commit with git-log","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2011-01-28T20:29:41Z","receivedAt":"2011-01-28T20:29:41Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 26.01.2011 19:11, schrieb René Scharfe:\n> So far we have two action items, I think:\n> \n> - Make git grep report non-matching path specs (new feature).\n> \n> - Find out why removing the last path component made a difference in\n> the case above (looks like a bug, but I don't understand what's going\n> on).\n\nOK, regarding the second point:\n\nMerges that have at least one parent without changes in the selected\nsubset of files won't be displayed, not even with --full-history. That\nexplains why removing the last path component made a difference: all the\nmerges ended up with a version of the file that matched one of their\nparents, but there were other changes in the directory.\n\nThis is a feature: since the version of the file picked by the merge\nmust have been introduced by an earlier commit (a regular one,\npresumably), you'll find it there anyway.\n\nAnd this history simplification takes precedence over pickaxe (-S).\n\nThe patch below turns down its aggressiveness when the pickaxe is swung\nat the same time. Here's what it does to your use case:\n\n\t$ revs=\"v2.6.26..v2.6.29\"\n\t$ opts=\"-Sblacklist_iommu --oneline -m --full-history\"\n\n\t# This takes quite a while...\n\t$ git log $opts $revs | wc -l\n\t160\n\n\t# Without the patch:\n\t$ git log $opts $revs -- drivers/pci/intel-iommu.c | wc -l\n\t2\n\n\t# With the patch (really just its first hunk):\n\t$ git log $opts $revs -- drivers/pci/intel-iommu.c | wc -l\n\t160\n\n\t$ opts=\"-Sblacklist_iommu --oneline -m\"\n\n\t# This takes quite a while...\n\t$ git log $opts $revs | wc -l\n\t160\n\n\t# Without the patch:\n\t$ git log $opts $revs -- drivers/pci/intel-iommu.c | wc -l\n\t0\n\n\t# With the patch:\n\t$ git log $opts $revs -- drivers/pci/intel-iommu.c | wc -l\n\t160\n\n\t$ opts=\"-Sblacklist_iommu --oneline\"\n\n\t# This takes a bit, but not too long.\n\t$ git log $opts $revs | wc -l\n\t1\n\n\t# Without the patch:\n\t$ git log $opts $revs -- drivers/pci/intel-iommu.c | wc -l\n\t0\n\n\t# With the patch:\n\t$ git log $opts $revs -- drivers/pci/intel-iommu.c | wc -l\n\t1\n\nThe full output matches exactly if the number of lines match. That's to\nbe expected, as the string \"blacklist_iommu\" only ever appears in the\nfile drivers/pci/intel-iommu.c.\n\nIt wasn't mentioned before v2.6.26 or after v2.6.29.\n\nThere is only one regular commit, namely the initial one that introduced\nthe function. Some merges are reported more than once, each for every\nparent where -S hit. 135 unique commits are reported.\n\n-- >8 --\nSubject: pickaxe: don't simplify history too much\n\nIf pickaxe is used, turn off history simplification and make sure to keep\nmerges with at least one interesting parent.\n\nIf path specs are used, merges that have at least one parent whose files\nmatch those in the specified subset are edited out. This is good in\ngeneral, but leads to unexpectedly few results if used together with\npickaxe. Merges that also have an interesting parent (in terms of -S or\n-G) are dropped, too.\n\nThis change makes sure pickaxe takes precedence over history\nsimplification. This means path specs won't change the results as long\nas they contain all the files that pickaxe turns up. E.g. these two\ncommands now report the same single commit that added the function\nblacklist_iommu to the specified file in the Linux kernel repo:\n\n $ git log -Sblacklist_iommu v2.6.26..v2.6.29 --\n $ git log -Sblacklist_iommu v2.6.26..v2.6.29 -- drivers/pci/intel-iommu.c\n\nPreviously the second one came up empty.\n\nReported-by: Francis Moreau \nSigned-off-by: Rene Scharfe \n---\n revision.c | 5 +++++\n t/t6012-rev-list-simplify.sh | 2 ++\n 2 files changed, 7 insertions(+), 0 deletions(-)\n\ndiff --git a/revision.c b/revision.c\nindex 7b9eaef..cacf60c 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -441,6 +441,8 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)\n \t}\n \tif (tree_changed && !tree_same)\n \t\treturn;\n+\tif (tree_changed && revs->diffopt.pickaxe)\n+\t\treturn;\n \tcommit->object.flags |= TREESAME;\n }\n \n@@ -1647,6 +1649,9 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, struct s\n \t revs->diffopt.filter ||\n \t DIFF_OPT_TST(&revs->diffopt, FOLLOW_RENAMES))\n \t\trevs->diff = 1;\n+\n+\tif (revs->diffopt.pickaxe)\n+\t\trevs->simplify_history = 0;\n \n \tif (revs->topo_order)\n \t\trevs->limited = 1;\ndiff --git a/t/t6012-rev-list-simplify.sh b/t/t6012-rev-list-simplify.sh\nindex af34a1e..b4fb8d0 100755\n--- a/t/t6012-rev-list-simplify.sh\n+++ b/t/t6012-rev-list-simplify.sh\n@@ -86,5 +86,7 @@ check_result 'I H E C B A' --full-history --date-order -- file\n check_result 'I E C B A' --simplify-merges -- file\n check_result 'I B A' -- file\n check_result 'I B A' --topo-order -- file\n+check_result 'I C B' -SHello\n+check_result 'I C B' -SHello -- file\n \n test_done\n-- \n1.7.3.4\n"},{"id":"160011","messageId":"4D433CA7.9060200@lsrfire.ath.cx","threadId":"26333","inReplyTo":"4D4063EC.7090509@lsrfire.ath.cx","subject":"Re: Can't find the revelant commit with git-log","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2011-01-28T22:01:11Z","receivedAt":"2011-01-28T22:01:11Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 26.01.2011 19:11, schrieb René Scharfe:\n> - Make git grep report non-matching path specs (new feature).\n\nThis is a bit complicated because grep can work on files, index entries\nas well as versioned objects and supports wildcards, so it's not that\neasy to tell if a path spec matches something or is a rather typo. But\nit's not impossible either, of course.\n\nWhat you can do until someone implements it is to simply omit the double\ndash. Path specs are then looked up as revs and files and you'll get an\nerror if they can't be found:\n\n\t# In the Linux kernel repo; we enter the wrong directory:\n\t$ cd drivers\n\t$ git grep blacklist_iommu v2.6.27 intel-iommu.c\n\tfatal: ambiguous argument 'intel-iommu.c': unknown revision or path not in the working tree.\n\tUse '--' to separate paths from revisions\n\n\t# Now we enter the right one and try again:\n\t$ cd pci\n\t$ git grep blacklist_iommu v2.6.27 intel-iommu.c\n\tv2.6.27:intel-iommu.c:static int blacklist_iommu(const struct dmi_system_id *id)\n\tv2.6.27:intel-iommu.c:\t\t.callback = blacklist_iommu,\n\nThis won't work in bare repos or with wildcards, but it's better than\nnothing. And it saves you a few keystrokes.\n\nRené\n"},{"id":"160013","messageId":"7v1v3wd1al.fsf@alter.siamese.dyndns.org","threadId":"26333","inReplyTo":"4D432735.8000208@lsrfire.ath.cx","subject":"Re: Can't find the revelant commit with git-log","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-01-29T00:02:58Z","receivedAt":"2011-01-29T00:02:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"René Scharfe writes:\n\n> Subject: pickaxe: don't simplify history too much\n>\n> If pickaxe is used, turn off history simplification and make sure to keep\n> merges with at least one interesting parent.\n>\n> If path specs are used, merges that have at least one parent whose files\n> match those in the specified subset are edited out. This is good in\n> general, but leads to unexpectedly few results if used together with\n> pickaxe. Merges that also have an interesting parent (in terms of -S or\n> -G) are dropped, too.\n>\n> This change makes sure pickaxe takes precedence over history\n> simplification.\n\nHmmm, I understand the _motivation_ behind the change in the second hunk,\nin that you _might_ want to dig the side branch that did not contribute\nanything to the end result when looking for a needle with either -S or -G,\nbut doesn't the same logic apply to things like --grep?\n\nI do not think it is a good idea to unconditionally disable simplification\nfor -S/G without a way for the user to countermand (even though I could be\npersuaded to say that the flipping the default for -S/-G/--grep might have\nbeen a better alternative in hindsight).\n\nThe user can control this behaviour by giving or not giving --simplify\nfrom the command line anyway, no?\n\nAs to the first hunk, I have no idea why this is a good change.\n\nIt feels as if you are fighting against what this part of the code does in\ntry_to_simplify_commit():\n\n\tswitch (rev_compare_tree(revs, p, commit)) {\n\tcase REV_TREE_SAME:\n\t\ttree_same = 1;\n\t\tif (!revs->simplify_history || (p->object.flags & UNINTERESTING)) {\n\t\t\t/* ... */\n\t\t\tpp = &parent->next;\n\t\t\tcontinue;\n\t\t}\n\t\tparent->next = NULL;\n\t\tcommit->parents = parent;\n\t\tcommit->object.flags |= TREESAME;\n\t\treturn;\n\t...\n\nWhen we see a _single_ parent that has the same tree, we set tree_same and\nalso cull the parent list to contain only that parent. When we are not\nsimplifying the history, we do not cull the parent list and will inspect\nother parents as well, but still we set tree_same to 1 here. When some\nother parent is found to be different, we set tree_changed to 1. So we\nhave four states (same = (0, 1) x changed = (0, 1)).\n\nThe code before your addition in the first hunk says that we keep the\ncommit if there is no parent with the same contents (i.e. !tree_same) and\nthere is at least one parent with different contents (i.e. tree_changed).\nI suspect that this logic may not be working well when we do not simplify\nthe merge.\n\nLet's look at the original code before your patch again.\n\n 1. If all the parents of a commit are the same, we will see (tree_same &&\n !tree_changed), so we get TREESAME.\n\n 2. If some but not all of the parents are the same, we will see (tree_same\n && tree_changed), and we end up getting TREESAME.\n\n 3. If none of the parents is the same, (!tree_same && tree_changed) holds\n true, and we do not get TREESAME.\n\nPerhaps the second condition needs to be tweaked for the \"do not simplify\nmerges\" case? That is, we split 2. into two cases:\n\n 2a. When simplifying the merges, if any of the parents is the same as the\n commit, we say TREESAME (the same as before);\n\n 2b. When not simplifying, we say TREESAME only when all the parents are\n the same as the commit. Otherwise the merge commit itself is worth\n showing, i.e. !TREESAME.\n\nBut I probably am missing some corner cases you saw in your analysis...\n\ndiff --git a/revision.c b/revision.c\nindex 7b9eaef..0147124 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -439,7 +439,7 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)\n \t\t}\n \t\tdie(\"bad tree compare for commit %s\", sha1_to_hex(commit->object.sha1));\n \t}\n-\tif (tree_changed && !tree_same)\n+\tif ((!revs->simplify_history && tree_changed) || !tree_same)\n \t\treturn;\n \tcommit->object.flags |= TREESAME;\n }\n"},{"id":"160015","messageId":"4D437CA0.1070006@lsrfire.ath.cx","threadId":"26333","inReplyTo":"7v1v3wd1al.fsf@alter.siamese.dyndns.org","subject":"Re: Can't find the revelant commit with git-log","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2011-01-29T02:34:08Z","receivedAt":"2011-01-29T02:34:08Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 29.01.2011 01:02, schrieb Junio C Hamano:\n> René Scharfe writes:\n> \n>> Subject: pickaxe: don't simplify history too much\n>>\n>> If pickaxe is used, turn off history simplification and make sure to keep\n>> merges with at least one interesting parent.\n>>\n>> If path specs are used, merges that have at least one parent whose files\n>> match those in the specified subset are edited out. This is good in\n>> general, but leads to unexpectedly few results if used together with\n>> pickaxe. Merges that also have an interesting parent (in terms of -S or\n>> -G) are dropped, too.\n>>\n>> This change makes sure pickaxe takes precedence over history\n>> simplification.\n> \n> Hmmm, I understand the _motivation_ behind the change in the second hunk,\n> in that you _might_ want to dig the side branch that did not contribute\n> anything to the end result when looking for a needle with either -S or -G,\n> but doesn't the same logic apply to things like --grep?\n\nYes, that's true. I have to admit that I'm mostly reacting to the\nunintuitive output given in the specific case (\"test driven\") and\nprobably don't fully understand the underlying problem and all its\nimplications.\n\n> I do not think it is a good idea to unconditionally disable simplification\n> for -S/G without a way for the user to countermand (even though I could be\n> persuaded to say that the flipping the default for -S/-G/--grep might have\n> been a better alternative in hindsight).\n\nCurrently there is no way to turn simplification off, resulting in\ncertain commits to become invisible when using e.g. -S in combination\nwith path specs.\n\n> The user can control this behaviour by giving or not giving --simplify\n> from the command line anyway, no?\n\nYes, but that goes only so far (see the examples in the parent post\nwhich use --full-history; --simplify-merges gives 3 more results with\n-m, but still not the full 160).\n\nAnd as a user I don't want to have to add another option in order to use\npickaxe with path specs. My expectation is that my search has\nprecedence over any history simplification, which is a nice and\nnecessary optimization, but shouldn't hide any search results that I\nwould have got if I had used no path specs.\n\nHowever, it definitely looks like a corner case and I still don't know\nwhat happened with all these merges.\n\n> As to the first hunk, I have no idea why this is a good change.\n\nI didn't see any other way to fix the example given in the commit message..\n\n> It feels as if you are fighting against what this part of the code does in\n> try_to_simplify_commit():\n> \n> \tswitch (rev_compare_tree(revs, p, commit)) {\n> \tcase REV_TREE_SAME:\n> \t\ttree_same = 1;\n> \t\tif (!revs->simplify_history || (p->object.flags & UNINTERESTING)) {\n> \t\t\t/* ... */\n> \t\t\tpp = &parent->next;\n> \t\t\tcontinue;\n> \t\t}\n> \t\tparent->next = NULL;\n> \t\tcommit->parents = parent;\n> \t\tcommit->object.flags |= TREESAME;\n> \t\treturn;\n> \t...\n> \n> When we see a _single_ parent that has the same tree, we set tree_same and\n> also cull the parent list to contain only that parent. When we are not\n> simplifying the history, we do not cull the parent list and will inspect\n> other parents as well, but still we set tree_same to 1 here. When some\n> other parent is found to be different, we set tree_changed to 1. So we\n> have four states (same = (0, 1) x changed = (0, 1)).\n> \n> The code before your addition in the first hunk says that we keep the\n> commit if there is no parent with the same contents (i.e. !tree_same) and\n> there is at least one parent with different contents (i.e. tree_changed).\n> I suspect that this logic may not be working well when we do not simplify\n> the merge.\n> \n> Let's look at the original code before your patch again.\n> \n> 1. If all the parents of a commit are the same, we will see (tree_same &&\n> !tree_changed), so we get TREESAME.\n> \n> 2. If some but not all of the parents are the same, we will see (tree_same\n> && tree_changed), and we end up getting TREESAME.\n> \n> 3. If none of the parents is the same, (!tree_same && tree_changed) holds\n> true, and we do not get TREESAME.\n\nFor completeness, a fourth case (!tree_same && !tree_changed), which\nwould be triggered by commits whose parents are all classified as\nREV_TREE_NEW. That's another corner case for sure, but the old code\nwould mark it TREESAME and your patch changes that.\n\n> Perhaps the second condition needs to be tweaked for the \"do not simplify\n> merges\" case? That is, we split 2. into two cases:\n> \n> 2a. When simplifying the merges, if any of the parents is the same as the\n> commit, we say TREESAME (the same as before);\n> \n> 2b. When not simplifying, we say TREESAME only when all the parents are\n> the same as the commit. Otherwise the merge commit itself is worth\n> showing, i.e. !TREESAME.\n> \n> But I probably am missing some corner cases you saw in your analysis...\n> \n> diff --git a/revision.c b/revision.c\n> index 7b9eaef..0147124 100644\n> --- a/revision.c\n> +++ b/revision.c\n> @@ -439,7 +439,7 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)\n> \t\t}\n> \t\tdie(\"bad tree compare for commit %s\", sha1_to_hex(commit->object.sha1));\n> \t}\n> -\tif (tree_changed && !tree_same)\n> +\tif ((!revs->simplify_history && tree_changed) || !tree_same)\n> \t\treturn;\n> \tcommit->object.flags |= TREESAME;\n> }\n\nThe patch lists the right commits in the test case, but requires the\noption --full-history to be given. Without it no output is given if the\nfull file name is specified, as in master.\n\nPerhaps we should check my underlying assumption first: is it reasonable\nto expect a git log command to show the same commits with and without a\npath spec that covers all changed files?\n\nRené\n"},{"id":"160021","messageId":"7vsjwcb6rh.fsf@alter.siamese.dyndns.org","threadId":"26333","inReplyTo":"4D437CA0.1070006@lsrfire.ath.cx","subject":"Re: Can't find the revelant commit with git-log","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-01-29T05:47:46Z","receivedAt":"2011-01-29T05:47:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"René Scharfe writes:\n\n> Perhaps we should check my underlying assumption first: is it reasonable\n> to expect a git log command to show the same commits with and without a\n> path spec that covers all changed files?\n\nThe simplest case would be \"git log .\" vs \"git log\" from the root level of\nthe repository, right? Traditionally, the former is \"please show _one_\nsimplest history that can explain how the current commit came to be\"\n(i.e. with merge simplification), while the latter is \"please list\neverything that is behind the current commit\" (i.e. without), I think.\n\nIt feels unintuitive, but my understanding of the rationale behind the\ndesign is that, the expectation Linus had when he first did the pathspec\nlimited traversal was that most of the time \"git log $path\" is used to get\nan explanation. It follows that having to say \"git log --simplify $path\"\nwould have been a nuisance, so \"with pathspec, we simplify\" was thought to\nbe a reasonable default.\n"},{"id":"160024","messageId":"m2sjwb6feo.fsf@gmail.com","threadId":"26333","inReplyTo":"4D433CA7.9060200@lsrfire.ath.cx","subject":"Re: Can't find the revelant commit with git-log","fromName":"Francis Moreau","fromEmail":"francis.moro@gmail.com","sentAt":"2011-01-29T12:52:15Z","receivedAt":"2011-01-29T12:52:15Z","isPatch":false,"sender":{"key":"francis.moro@gmail.com","avatar":null},"body":"René Scharfe writes:\n\n> Am 26.01.2011 19:11, schrieb René Scharfe:\n>> - Make git grep report non-matching path specs (new feature).\n>\n> This is a bit complicated because grep can work on files, index entries\n> as well as versioned objects and supports wildcards,\n> so it's not that easy to tell if a path spec matches something or is a\n> rather typo. But it's not impossible either, of course.\n\nI don't understand this for the following use case:\n\n $ cd ~/linux-2.6/drivers/pci/\n $ git grep blacklist v2.6.27 -- drivers/pci/intel-iommu.c\n\nFrom what you said, it sounds that git grep is actually searching the\nstring 'somewhere'. But where ?\n\nThanks\n-- \nFrancis\n"},{"id":"160025","messageId":"4D440FED.2010203@lsrfire.ath.cx","threadId":"26333","inReplyTo":"m2sjwb6feo.fsf@gmail.com","subject":"Re: Can't find the revelant commit with git-log","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2011-01-29T13:02:37Z","receivedAt":"2011-01-29T13:02:37Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 29.01.2011 13:52, schrieb Francis Moreau:\n> René Scharfe writes:\n> \n>> Am 26.01.2011 19:11, schrieb René Scharfe:\n>>> - Make git grep report non-matching path specs (new feature).\n>>\n>> This is a bit complicated because grep can work on files, index entries\n>> as well as versioned objects and supports wildcards,\n>> so it's not that easy to tell if a path spec matches something or is a\n>> rather typo. But it's not impossible either, of course.\n> \n> I don't understand this for the following use case:\n> \n> $ cd ~/linux-2.6/drivers/pci/\n> $ git grep blacklist v2.6.27 -- drivers/pci/intel-iommu.c\n> \n> From what you said, it sounds that git grep is actually searching the\n> string 'somewhere'. But where ?\n\nAll files in the directory are looked at and checked if they match the\ngiven path spec first. Since none of them do, no actual text search has\nto take place.\n\nRené\n"},{"id":"160026","messageId":"m2k4hn6cek.fsf@gmail.com","threadId":"26333","inReplyTo":"4D440FED.2010203@lsrfire.ath.cx","subject":"Re: Can't find the revelant commit with git-log","fromName":"Francis Moreau","fromEmail":"francis.moro@gmail.com","sentAt":"2011-01-29T13:57:07Z","receivedAt":"2011-01-29T13:57:07Z","isPatch":false,"sender":{"key":"francis.moro@gmail.com","avatar":null},"body":"René Scharfe writes:\n\n> Am 29.01.2011 13:52, schrieb Francis Moreau:\n>> René Scharfe writes:\n>> \n>>> Am 26.01.2011 19:11, schrieb René Scharfe:\n>\n>>>> - Make git grep report non-matching path specs (new feature).\n>>>\n>>> This is a bit complicated because grep can work on files, index entries\n>>> as well as versioned objects and supports wildcards,\n>>> so it's not that easy to tell if a path spec matches something or is a\n>>> rather typo. But it's not impossible either, of course.\n>> \n>> I don't understand this for the following use case:\n>> \n>> $ cd ~/linux-2.6/drivers/pci/\n>> $ git grep blacklist v2.6.27 -- drivers/pci/intel-iommu.c\n>> \n>> From what you said, it sounds that git grep is actually searching the\n>> string 'somewhere'. But where ?\n>\n> All files in the directory are looked at and checked if they match the\n> given path spec first. Since none of them do, no actual text search has\n> to take place.\n\nand in this case, it is complicated to tell that the given path spec\nmatch nothing. right ?\n\n-- \nFrancis\n"},{"id":"160027","messageId":"4D442FA6.8000504@lsrfire.ath.cx","threadId":"26333","inReplyTo":"m2k4hn6cek.fsf@gmail.com","subject":"Re: Can't find the revelant commit with git-log","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2011-01-29T15:17:58Z","receivedAt":"2011-01-29T15:17:58Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 29.01.2011 14:57, schrieb Francis Moreau:\n> René Scharfe writes:\n> \n>> Am 29.01.2011 13:52, schrieb Francis Moreau:\n>>> René Scharfe writes:\n>>>\n>>>> Am 26.01.2011 19:11, schrieb René Scharfe:\n>>\n>>>>> - Make git grep report non-matching path specs (new feature).\n>>>>\n>>>> This is a bit complicated because grep can work on files, index entries\n>>>> as well as versioned objects and supports wildcards,\n>>>> so it's not that easy to tell if a path spec matches something or is a\n>>>> rather typo. But it's not impossible either, of course.\n>>>\n>>> I don't understand this for the following use case:\n>>>\n>>> $ cd ~/linux-2.6/drivers/pci/\n>>> $ git grep blacklist v2.6.27 -- drivers/pci/intel-iommu.c\n>>>\n>>> From what you said, it sounds that git grep is actually searching the\n>>> string 'somewhere'. But where ?\n>>\n>> All files in the directory are looked at and checked if they match the\n>> given path spec first. Since none of them do, no actual text search has\n>> to take place.\n> \n> and in this case, it is complicated to tell that the given path spec\n> match nothing. right ?\n\nThe specific case is easy to handle, but a complete solution would have\nto address files, index entries as well as versioned objects and support\nwildcards. Presumably it would come on top of Duy's pathspec work\nthat's in next now.\n\nRené\n"},{"id":"160036","messageId":"4D4477E4.6020006@lsrfire.ath.cx","threadId":"26333","inReplyTo":"7vsjwcb6rh.fsf@alter.siamese.dyndns.org","subject":"Re: Can't find the revelant commit with git-log","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2011-01-29T20:26:12Z","receivedAt":"2011-01-29T20:26:12Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 29.01.2011 06:47, schrieb Junio C Hamano:\n> René Scharfe writes:\n> \n>> Perhaps we should check my underlying assumption first: is it\n>> reasonable to expect a git log command to show the same commits\n>> with and without a path spec that covers all changed files?\n> \n> The simplest case would be \"git log .\" vs \"git log\" from the root\n> level of the repository, right? Traditionally, the former is \"please\n> show _one_ simplest history that can explain how the current commit\n> came to be\" (i.e. with merge simplification), while the latter is\n> \"please list everything that is behind the current commit\" (i.e.\n> without), I think.\n> \n> It feels unintuitive, but my understanding of the rationale behind\n> the design is that, the expectation Linus had when he first did the\n> pathspec limited traversal was that most of the time \"git log $path\"\n> is used to get an explanation. It follows that having to say \"git\n> log --simplify $path\" would have been a nuisance, so \"with pathspec,\n> we simplify\" was thought to be a reasonable default.\n\nI think simplifying the history whenever a pathspec restricts the set of\ninteresting commits makes sense.\n\nI'm not so sure about \".\" vs. none, and it feels odd that the only way\nto turn off simplification is to not use pathspecs, as --full-history\nwill still remove merges if tree_same in revision.c is true.\nSimplification by default (even without a pathspec) and --full-history\nreporting, well, the full history seems more intuitive to me.\n\nSo currently pickaxe can't be used reliable to search for strings that\nhave been removed: either one has to refrain from using pathspecs, which\nis prohibitively slow in the kernel repo, or git is free to take a\nshort-cut through a branch of history that never contained the string at\nall.\n\nYour patch extends --full-history coverage sufficiently to make pickaxe\nwork in Francis' use case. One just has to remember to specify this\noption if one hunts for removed strings using -S. Below is an equivalent\npatch, only with the simplify_history test moved into the loop and the\nneeded test script modification.\n\n-- >8 --\nSubject: revision: let --full-history keep half-interesting merges\n\nDon't simplify merges away that have at least one parent with changes in\nthe interesting subset of files if --full-history has been specified.\nThe previous behaviour hid merges with one uninteresting parent, which\ncould lead to history that removed code to become undetectable.\n\nE.g., this command run against the Linux kernel repo only found one\nmerge that brought the specified function in (and the regular commit\nwhich added it in the first place), but missed the 92 merges that\nremoved it, as well as 67 other merges that added it back:\n\n\t$ git log -m --full-history -Sblacklist_iommu \\\n\t\tv2.6.26..v2.6.29 -- drivers/pci/intel-iommu.c\n\nReported-by: Francis Moreau \nSigned-off-by: Rene Scharfe \n---\n revision.c | 2 ++\n t/t6016-rev-list-graph-simplify-history.sh | 1 +\n 2 files changed, 3 insertions(+), 0 deletions(-)\n\ndiff --git a/revision.c b/revision.c\nindex 7b9eaef..84c231b 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -434,6 +434,8 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)\n \t\tcase REV_TREE_OLD:\n \t\tcase REV_TREE_DIFFERENT:\n \t\t\ttree_changed = 1;\n+\t\t\tif (!revs->simplify_history)\n+\t\t\t\treturn;\n \t\t\tpp = &parent->next;\n \t\t\tcontinue;\n \t\t}\ndiff --git a/t/t6016-rev-list-graph-simplify-history.sh b/t/t6016-rev-list-graph-simplify-history.sh\nindex f7181d1..50ffcf4 100755\n--- a/t/t6016-rev-list-graph-simplify-history.sh\n+++ b/t/t6016-rev-list-graph-simplify-history.sh\n@@ -168,6 +168,7 @@ test_expect_success '--graph --full-history --simplify-merges -- bar.txt' '\n \techo \"|\\\\ \" >> expected &&\n \techo \"| * $C4\" >> expected &&\n \techo \"* | $A5\" >> expected &&\n+\techo \"* | $A4\" >> expected &&\n \techo \"* | $A3\" >> expected &&\n \techo \"|/ \" >> expected &&\n \techo \"* $A2\" >> expected &&\n-- \n1.7.3.4\n"},{"id":"160035","messageId":"4D4477E8.8030703@lsrfire.ath.cx","threadId":"26333","inReplyTo":"4D437CA0.1070006@lsrfire.ath.cx","subject":"Re: Can't find the revelant commit with git-log","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2011-01-29T20:26:16Z","receivedAt":"2011-01-29T20:26:16Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 29.01.2011 03:34, schrieb René Scharfe:\n> Am 29.01.2011 01:02, schrieb Junio C Hamano:\n>> Let's look at the original code before your patch again.\n>>\n>> 1. If all the parents of a commit are the same, we will see (tree_same &&\n>> !tree_changed), so we get TREESAME.\n>>\n>> 2. If some but not all of the parents are the same, we will see (tree_same\n>> && tree_changed), and we end up getting TREESAME.\n>>\n>> 3. If none of the parents is the same, (!tree_same && tree_changed) holds\n>> true, and we do not get TREESAME.\n> \n> For completeness, a fourth case (!tree_same && !tree_changed), which\n> would be triggered by commits whose parents are all classified as\n> REV_TREE_NEW. That's another corner case for sure, but the old code\n> would mark it TREESAME and your patch changes that.\n\nUgh, forget this part, I failed to notice the /* fallthrough */ at the\nend of the REV_TREE_NEW case..\n\nRené\n"},{"id":"160221","messageId":"7vr5brzbpb.fsf@alter.siamese.dyndns.org","threadId":"26333","inReplyTo":"4D4477E4.6020006@lsrfire.ath.cx","subject":"Re: Can't find the revelant commit with git-log","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-01T21:28:32Z","receivedAt":"2011-02-01T21:28:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"René Scharfe writes:\n\n> Subject: revision: let --full-history keep half-interesting merges\n>\n> Don't simplify merges away that have at least one parent with changes in\n> the interesting subset of files if --full-history has been specified.\n> The previous behaviour hid merges with one uninteresting parent, which\n> could lead to history that removed code to become undetectable.\n\nI think this patch makes a lot more sense than what I've seen in this\nthread (including mine).\n\n> E.g., this command run against the Linux kernel repo only found one\n> merge that brought the specified function in (and the regular commit\n> which added it in the first place), but missed the 92 merges that\n> removed it, as well as 67 other merges that added it back:\n>\n> \t$ git log -m --full-history -Sblacklist_iommu \\\n> \t\tv2.6.26..v2.6.29 -- drivers/pci/intel-iommu.c\n>\n> Reported-by: Francis Moreau \n> Signed-off-by: Rene Scharfe \n\nThanks.\n\n> ---\n> revision.c | 2 ++\n> t/t6016-rev-list-graph-simplify-history.sh | 1 +\n> 2 files changed, 3 insertions(+), 0 deletions(-)\n>\n> diff --git a/revision.c b/revision.c\n> index 7b9eaef..84c231b 100644\n> --- a/revision.c\n> +++ b/revision.c\n> @@ -434,6 +434,8 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)\n> \t\tcase REV_TREE_OLD:\n> \t\tcase REV_TREE_DIFFERENT:\n> \t\t\ttree_changed = 1;\n> +\t\t\tif (!revs->simplify_history)\n> +\t\t\t\treturn;\n> \t\t\tpp = &parent->next;\n> \t\t\tcontinue;\n> \t\t}\n> diff --git a/t/t6016-rev-list-graph-simplify-history.sh b/t/t6016-rev-list-graph-simplify-history.sh\n> index f7181d1..50ffcf4 100755\n> --- a/t/t6016-rev-list-graph-simplify-history.sh\n> +++ b/t/t6016-rev-list-graph-simplify-history.sh\n> @@ -168,6 +168,7 @@ test_expect_success '--graph --full-history --simplify-merges -- bar.txt' '\n> \techo \"|\\\\ \" >> expected &&\n> \techo \"| * $C4\" >> expected &&\n> \techo \"* | $A5\" >> expected &&\n> +\techo \"* | $A4\" >> expected &&\n> \techo \"* | $A3\" >> expected &&\n> \techo \"|/ \" >> expected &&\n> \techo \"* $A2\" >> expected &&\n> -- \n> 1.7.3.4\n"},{"id":"160654","messageId":"7vk4hbsbjr.fsf@alter.siamese.dyndns.org","threadId":"26333","inReplyTo":"4D4477E4.6020006@lsrfire.ath.cx","subject":"Re: Can't find the revelant commit with git-log","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-07T22:51:52Z","receivedAt":"2011-02-07T22:51:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"René Scharfe writes:\n\n> diff --git a/t/t6016-rev-list-graph-simplify-history.sh b/t/t6016-rev-list-graph-simplify-history.sh\n> index f7181d1..50ffcf4 100755\n> --- a/t/t6016-rev-list-graph-simplify-history.sh\n> +++ b/t/t6016-rev-list-graph-simplify-history.sh\n> @@ -168,6 +168,7 @@ test_expect_success '--graph --full-history --simplify-merges -- bar.txt' '\n> \techo \"|\\\\ \" >> expected &&\n> \techo \"| * $C4\" >> expected &&\n> \techo \"* | $A5\" >> expected &&\n> +\techo \"* | $A4\" >> expected &&\n> \techo \"* | $A3\" >> expected &&\n> \techo \"|/ \" >> expected &&\n> \techo \"* $A2\" >> expected &&\n\nThanks for a patch with a test; I am not sure if this is quite correct,\nthough.\n\nA4 has three parents, C2, A3 and B2, and does not introduce any change\nwith respect to bar.txt. A6 has bar.txt identical to that of A5, but we\ncannot omit it because we are showing its two parents (A5 and C4), and\nthat is why we show it. A4 isn't even gets shown as a merge, so I don't\nunderstand why we need to show it?\n\nDon't we need to also adjust the simplify-merges codepath to take this\nchange into account, or something?\n"},{"id":"160830","messageId":"4D54337B.6040307@lsrfire.ath.cx","threadId":"26333","inReplyTo":"7vk4hbsbjr.fsf@alter.siamese.dyndns.org","subject":"Re: Can't find the revelant commit with git-log","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2011-02-10T18:50:35Z","receivedAt":"2011-02-10T18:50:35Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 07.02.2011 23:51, schrieb Junio C Hamano:\n> René Scharfe writes:\n>\n>> diff --git a/t/t6016-rev-list-graph-simplify-history.sh b/t/t6016-rev-list-graph-simplify-history.sh\n>> index f7181d1..50ffcf4 100755\n>> --- a/t/t6016-rev-list-graph-simplify-history.sh\n>> +++ b/t/t6016-rev-list-graph-simplify-history.sh\n>> @@ -168,6 +168,7 @@ test_expect_success '--graph --full-history --simplify-merges -- bar.txt' '\n>> \techo \"|\\\\ \">> expected&&\n>> \techo \"| * $C4\">> expected&&\n>> \techo \"* | $A5\">> expected&&\n>> +\techo \"* | $A4\">> expected&&\n>> \techo \"* | $A3\">> expected&&\n>> \techo \"|/ \">> expected&&\n>> \techo \"* $A2\">> expected&&\n>\n> Thanks for a patch with a test; I am not sure if this is quite correct,\n> though.\n>\n> A4 has three parents, C2, A3 and B2, and does not introduce any change\n> with respect to bar.txt. A6 has bar.txt identical to that of A5, but we\n> cannot omit it because we are showing its two parents (A5 and C4), and\n> that is why we show it. A4 isn't even gets shown as a merge, so I don't\n> understand why we need to show it?\n\nYes, this looks a bit silly on closer look. I thought that it matches \nFrancis' use case, but that's wrong -- having --simplify-merges instead \nof -Sstring makes a difference, obviously.\n\nAfter looking at the case again, I think I have a simpler solution: no \ncode change, just add --sparse (include all walked commits). This gives \nthe same results as the patched version:\n\n\t$ git log --oneline -m --sparse --full-history \\\n\t\t-Sblacklist_iommu v2.6.26..v2.6.29 -- \\\n\t\tdrivers/pci/intel-iommu.c | wc -l\n\t 160\n\nSorry for the noise.\n\nSo, the lesson would be: If you want to find commits that removed a \ncertain string in a certain set of files, add --full-history, -m and \n--sparse to your \"git log -Sstring -- files\" command. This allows you \nto catch merges that reverted those files to a state before the string \nwas introduced in the first place, otherwise history simplification can \nhide them.\n\nI'm not sure if there's a way to make the flags and their interactions \nmore intituitive.\n\nRené\n"}]}