{"thread":{"id":"26122","subject":"Expected behaviour of 'git log -S' when searching in a merged/deleted file?","startedAt":"2010-12-22T13:37:19Z","lastAt":"2010-12-23T17:27:39Z","messageCount":5,"participants":["Jonathan del Strother","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"158486","messageId":"AANLkTimXk6ei6EAQfvTTfnMzdBqYHkNoaxkEab+atnHd@mail.gmail.com","threadId":"26122","inReplyTo":null,"subject":"Expected behaviour of 'git log -S' when searching in a merged/deleted file?","fromName":"Jonathan del Strother","fromEmail":"jdelstrother@gmail.com","sentAt":"2010-12-22T13:37:19Z","receivedAt":"2010-12-22T13:37:19Z","isPatch":false,"sender":{"key":"jdelstrother@gmail.com","avatar":"https://gravatar.com/avatar/42e379ac542f06e3fc4282a9b97ddf25e79c67e4ade5c1fd3d6a9159942e138f?d=mp&s=160"},"body":"Hi,\n\nI was trying to find a particular string in my project this morning.\n'git grep mystring' suggested that the string didn't exist in my repo,\nbut 'git log -Smystring' turned up a single commit that had added it.\nIt took me a long time to figure out that in the past, a branch had\nadded that string to foo.c, but a second branch deleted foo.c, and the\ntwo branches were later merged (deleting foo.c and ignoring mystring).\n I was surprised that 'git log -S' didn't show the merge commit as the\npoint at which the string had been removed.\n\nI've attached a testcase which I would expect to pass (perhaps\nnaively), but doesn't. Is this a git bug, or do I misunderstand git\nlog -S?\n\n--\n\n\n#!/bin/sh\n\ntest_description='git log'\n\n. ./test-lib.sh\n\ntest_expect_success setup '\n\techo haystack\\\\nhaystack\\\\nhaystack\\\\nhaystack\\\\n > haystack &&\n\tgit add haystack &&\n\ttest_tick &&\n\tgit commit -m initial &&\n\n\tgit checkout -b branchA &&\n\techo needle >haystack &&\n\tgit add haystack &&\n\ttest_tick &&\n\tgit commit -m \"adding needle\" &&\n\n\tgit checkout -b branchB HEAD~1 &&\n\tgit rm haystack &&\n\ttest_tick &&\n\tgit commit -m \"removing haystack\" &&\n\n\tgit merge branchA || git rm haystack &&\n\ttest_tick &&\n\tgit commit -m \"merging: haystack and needle removed\"\n'\n\nprintf \"merging: haystack and needle removed\\nadding needle\" > expect\ntest_expect_success 'log -S in a merge-deleted file' '\n\n\tgit log -Sneedle --pretty=\"format:%s\" > actual &&\n\ttest_cmp expect actual\n'\n\ntest_done\n"},{"id":"158493","messageId":"7vzkrx4qp6.fsf@alter.siamese.dyndns.org","threadId":"26122","inReplyTo":"AANLkTimXk6ei6EAQfvTTfnMzdBqYHkNoaxkEab+atnHd@mail.gmail.com","subject":"Re: Expected behaviour of 'git log -S' when searching in a merged/deleted file?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-12-22T18:17:57Z","receivedAt":"2010-12-22T18:17:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan del Strother writes:\n\n> I was trying to find a particular string in my project this morning.\n> 'git grep mystring' suggested that the string didn't exist in my repo,\n> but 'git log -Smystring' turned up a single commit that had added it.\n> It took me a long time to figure out that in the past, a branch had\n> added that string to foo.c, but a second branch deleted foo.c, and the\n> two branches were later merged (deleting foo.c and ignoring mystring).\n\nThis is a typical case of the history simplification in action, isn't it?\n\n\"log\" will give you one possible and simplest explanation of how the\nproject came into the current shape. Because side branches with changes\nthat were discarded before merging it to the history that lead to the\ncommit you run \"log\" from do not contribute anything to the end result,\n\"log\" will not traverse the entire side branch when it sees the merge.\n\nTry your \"log\" with --full-history, perhaps?\n"},{"id":"158522","messageId":"AANLkTim4z3XvpjnEERuXgTE6CtA7D-dnBxSUgO3mE-FM@mail.gmail.com","threadId":"26122","inReplyTo":"7vzkrx4qp6.fsf@alter.siamese.dyndns.org","subject":"Re: Expected behaviour of 'git log -S' when searching in a merged/deleted file?","fromName":"Jonathan del Strother","fromEmail":"jdelstrother@gmail.com","sentAt":"2010-12-23T09:47:57Z","receivedAt":"2010-12-23T09:47:57Z","isPatch":false,"sender":{"key":"jdelstrother@gmail.com","avatar":"https://gravatar.com/avatar/42e379ac542f06e3fc4282a9b97ddf25e79c67e4ade5c1fd3d6a9159942e138f?d=mp&s=160"},"body":"On 22 December 2010 18:17, Junio C Hamano wrote:\n> Jonathan del Strother writes:\n>\n>> I was trying to find a particular string in my project this morning.\n>> 'git grep mystring' suggested that the string didn't exist in my repo,\n>> but 'git log -Smystring' turned up a single commit that had added it.\n>> It took me a long time to figure out that in the past, a branch had\n>> added that string to foo.c, but a second branch deleted foo.c, and the\n>> two branches were later merged (deleting foo.c and ignoring mystring).\n>\n> This is a typical case of the history simplification in action, isn't it?\n>\n> \"log\" will give you one possible and simplest explanation of how the\n> project came into the current shape.  Because side branches with changes\n> that were discarded before merging it to the history that lead to the\n> commit you run \"log\" from do not contribute anything to the end result,\n> \"log\" will not traverse the entire side branch when it sees the merge.\n\nI don't follow ... 'log' isn't showing me how the project came into\nit's current shape. In the test case I posted, for example, it's\nshowing me that 'needle' was added to the repository at some point,\nbut it neglects to mention that it was removed. If 'needle' was added\nand removed within the duration of a single branch, I could understand\n\"git log -S\" never finding 'needle' due to history simplication, but I\ndon't understand how simplification applies here.\n\n>\n> Try your \"log\" with --full-history, perhaps?\n\nDoesn't seem to affect the output in this case.\n"},{"id":"158526","messageId":"7vwrn0328p.fsf@alter.siamese.dyndns.org","threadId":"26122","inReplyTo":"AANLkTim4z3XvpjnEERuXgTE6CtA7D-dnBxSUgO3mE-FM@mail.gmail.com","subject":"Re: Expected behaviour of 'git log -S' when searching in a merged/deleted file?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-12-23T16:03:50Z","receivedAt":"2010-12-23T16:03:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan del Strother writes:\n\n> .... If 'needle' was added\n> and removed within the duration of a single branch, I could understand\n> \"git log -S\" never finding 'needle' due to history simplication, but I\n> don't understand how simplification applies here.\n\nAhh, sorry, I misunderstood the scenario. Just like you do not see a\npatch output from \"log -p\", the diff machinery (including -S and its newer\ncousin -G) does not kick in by default for merge commits (this is a bit of\nwhite lie as \"log -p\" defaults to \"combine diff\", i.e. be silent on any\nuninteresting merge that takes its results literally from either parent).\n\nPlease try it with \"-m\" (not \"--full-history\"). We _might_ want to change\nthis behaviour for -S/-G but it needs a bit more thought.\n"},{"id":"158534","messageId":"AANLkTinS6i0K4MMdr_E94ig-V3oMFZ+L7N=mqn0S3Y7T@mail.gmail.com","threadId":"26122","inReplyTo":"7vwrn0328p.fsf@alter.siamese.dyndns.org","subject":"Re: Expected behaviour of 'git log -S' when searching in a merged/deleted file?","fromName":"Jonathan del Strother","fromEmail":"jdelstrother@gmail.com","sentAt":"2010-12-23T17:27:39Z","receivedAt":"2010-12-23T17:27:39Z","isPatch":false,"sender":{"key":"jdelstrother@gmail.com","avatar":"https://gravatar.com/avatar/42e379ac542f06e3fc4282a9b97ddf25e79c67e4ade5c1fd3d6a9159942e138f?d=mp&s=160"},"body":"On 23 December 2010 16:03, Junio C Hamano wrote:\n> Jonathan del Strother writes:\n>\n>> ....  If 'needle' was added\n>> and removed within the duration of a single branch, I could understand\n>> \"git log -S\" never finding 'needle' due to history simplication, but I\n>> don't understand how simplification applies here.\n>\n> Ahh, sorry, I misunderstood the scenario.  Just like you do not see a\n> patch output from \"log -p\", the diff machinery (including -S and its newer\n> cousin -G) does not kick in by default for merge commits (this is a bit of\n> white lie as \"log -p\" defaults to \"combine diff\", i.e. be silent on any\n> uninteresting merge that takes its results literally from either parent).\n>\n> Please try it with \"-m\" (not \"--full-history\").  We _might_ want to change\n> this behaviour for -S/-G but it needs a bit more thought.\n>\n\nYep, '-m' produces the expected (or at least, *my* expected) results.\n"}]}