A little help understanding output from git blame --reverse

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

 



Hi!

While doing some research developing difflame I found some output from
git blame --reverse that I can't quite understand. Perhaps another set
of eyeballs could help me.

I'm "difflaming" HEAD~100 (02db2d0421b97fcb6211) and HEAD
(066fb0494e6398eb). Specifically file abspath.c.

If we diff (as in plain old git diff) HEAD~100..HEAD we can see that
line 63 (from HEAD~100 revision) was deleted between HEAD~100 and
HEAD:

@@ -58,86 +95,136 @@ blah blah
                       goto error_out;
       }

-       strbuf_reset(&sb);
-       strbuf_addstr(&sb, path);
-
-       while (depth--) {
-               if (!is_directory(sb.buf)) {


So, if I do a "reverse" blame operation on the file, I would expect to
see the last revision where that line was _present_ on the file:

c5f3cba126  61)         strbuf_reset(&sb);
c5f3cba126  62)         strbuf_addstr(&sb, path);
066fb0494e  63)
c5f3cba126  64)         while (depth--) {
c5f3cba126  65)                 if (!is_directory(sb.buf)) {

line 63 shows up as if it had been last present on the file on
revision 066fb0494e, which is HEAD, which kind of doesn't make a lot
of sense to me because given that the line is not present on the file
on HEAD (as we can guess from diff output) it means it was "forcefully
present" on some previous revision (and that's what I would expect to
see reported on blame --reverse output).

What am I missing? Thanks in advance.




[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]