Re: Expected behaviour of 'git log -S' when searching in a merged/deleted file?

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: Expected behaviour of 'git log -S' when searching in a merged/deleted file?

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:50:17

Jonathan del Strother [off-list ref] writes:
I was trying to find a particular string in my project this morning.
'git grep mystring' suggested that the string didn't exist in my repo,
but 'git log -Smystring' turned up a single commit that had added it.
It took me a long time to figure out that in the past, a branch had
added that string to foo.c, but a second branch deleted foo.c, and the
two branches were later merged (deleting foo.c and ignoring mystring).
This is a typical case of the history simplification in action, isn't it?

"log" will give you one possible and simplest explanation of how the
project came into the current shape.  Because side branches with changes
that were discarded before merging it to the history that lead to the
commit you run "log" from do not contribute anything to the end result,
"log" will not traverse the entire side branch when it sees the merge.

Try your "log" with --full-history, perhaps?

Re: Expected behaviour of 'git log -S' when searching in a merged/deleted file?

From: Jonathan del Strother <hidden>
Date: 2016-06-15 22:50:17

On 22 December 2010 18:17, Junio C Hamano [off-list ref] wrote:
Jonathan del Strother [off-list ref] writes:
quoted
I was trying to find a particular string in my project this morning.
'git grep mystring' suggested that the string didn't exist in my repo,
but 'git log -Smystring' turned up a single commit that had added it.
It took me a long time to figure out that in the past, a branch had
added that string to foo.c, but a second branch deleted foo.c, and the
two branches were later merged (deleting foo.c and ignoring mystring).
This is a typical case of the history simplification in action, isn't it?

"log" will give you one possible and simplest explanation of how the
project came into the current shape.  Because side branches with changes
that were discarded before merging it to the history that lead to the
commit you run "log" from do not contribute anything to the end result,
"log" will not traverse the entire side branch when it sees the merge.
I don't follow ...  'log' isn't showing me how the project came into
it's current shape. In the test case I posted, for example, it's
showing me that 'needle' was added to the repository at some point,
but it neglects to mention that it was removed.  If 'needle' was added
and removed within the duration of a single branch, I could understand
"git log -S" never finding 'needle' due to history simplication, but I
don't understand how simplification applies here.
Try your "log" with --full-history, perhaps?
Doesn't seem to affect the output in this case.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help