Re: Can't find the revelant commit with git-log
- From
René Scharfe <rene.scharfe@lsrfire.ath.cx>
- Date
- Feb 10, 2011, 18:50 UTC
- Message-ID
- <4D54337B.6040307@lsrfire.ath.cx>
- In-Reply-To
- <7vk4hbsbjr.fsf@alter.siamese.dyndns.org>
Am 07.02.2011 23:51, schrieb Junio C Hamano:
Show 23 quoted lines
> René Scharfe<rene.scharfe@lsrfire.ath.cx> writes: > >> diff --git a/t/t6016-rev-list-graph-simplify-history.sh b/t/t6016-rev-list-graph-simplify-history.sh >> index f7181d1..50ffcf4 100755 >> --- a/t/t6016-rev-list-graph-simplify-history.sh >> +++ b/t/t6016-rev-list-graph-simplify-history.sh >> @@ -168,6 +168,7 @@ test_expect_success '--graph --full-history --simplify-merges -- bar.txt' ' >> echo "|\\ ">> expected&& >> echo "| * $C4">> expected&& >> echo "* | $A5">> expected&& >> + echo "* | $A4">> expected&& >> echo "* | $A3">> expected&& >> echo "|/ ">> expected&& >> echo "* $A2">> expected&& > > Thanks for a patch with a test; I am not sure if this is quite correct, > though. > > A4 has three parents, C2, A3 and B2, and does not introduce any change > with respect to bar.txt. A6 has bar.txt identical to that of A5, but we > cannot omit it because we are showing its two parents (A5 and C4), and > that is why we show it. A4 isn't even gets shown as a merge, so I don't > understand why we need to show it?
Yes, this looks a bit silly on closer look. I thought that it matches Francis' use case, but that's wrong -- having --simplify-merges instead of -Sstring makes a difference, obviously.
After looking at the case again, I think I have a simpler solution: no code change, just add --sparse (include all walked commits). This gives the same results as the patched version:
$ git log --oneline -m --sparse --full-history \ -Sblacklist_iommu v2.6.26..v2.6.29 -- \ drivers/pci/intel-iommu.c | wc -l 160
Sorry for the noise.
So, the lesson would be: If you want to find commits that removed a certain string in a certain set of files, add --full-history, -m and --sparse to your "git log -Sstring -- files" command. This allows you to catch merges that reverted those files to a state before the string was introduced in the first place, otherwise history simplification can hide them.
I'm not sure if there's a way to make the flags and their interactions more intituitive.
René