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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jonathan del Strother <jdelstrother@xxxxxxxxx> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]