git-blame not tracking copies

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

 



Hello,

During the discussion on the ffmpeg list about potential migration to 
git the following came up.  It seems like a bug to me, so I said I 
would raise it here.

This is the output of a test script (which I can supply if wanted, but 
you can guess the content from the output.

Initialized empty Git repository in .git/
----- echo ABC to commit 1
Created initial commit beb7140: 1
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 newtest
----- echo DEF to commit 2
Created commit 207f5a3: 2
 1 files changed, 1 insertions(+), 0 deletions(-)
----- echo ghijk to commit 3
Created commit 14abf8c: 3
 1 files changed, 1 insertions(+), 0 deletions(-)
----- Blame 1...
^beb7140 (Andy Parkins 2007-05-02 20:25:27 +0100 1) ABC
207f5a35 (Andy Parkins 2007-05-02 20:25:27 +0100 2) DEF
14abf8ce (Andy Parkins 2007-05-02 20:25:27 +0100 3) ghijk
----- Copy newtest to newtest2, commit 4
Created commit 48861ce: 4
 1 files changed, 3 insertions(+), 0 deletions(-)
 create mode 100644 newtest2
----- Blame 2...
48861ced (Andy Parkins 2007-05-02 20:25:27 +0100 1) ABC
48861ced (Andy Parkins 2007-05-02 20:25:27 +0100 2) DEF
48861ced (Andy Parkins 2007-05-02 20:25:27 +0100 3) ghijk
----- Edit newtest2, commit 5
Created commit 2d2ec0f: 5
 1 files changed, 1 insertions(+), 0 deletions(-)
----- Blame 3...
^beb7140 newtest  (Andy Parkins 2007-05-02 20:25:27 +0100 1) ABC
207f5a35 newtest  (Andy Parkins 2007-05-02 20:25:27 +0100 2) DEF
2d2ec0f0 newtest2 (Andy Parkins 2007-05-02 20:25:27 +0100 3) XXXX
48861ced newtest2 (Andy Parkins 2007-05-02 20:25:27 +0100 4) ghijk

All git-blame commands are "git-blame -C1 -C1"

The issues are

 - Blame2 says all the lines come from commit 4, when actually they
   come from commits 1, 2 and 3.  It was pointed out that this is
   particularly annoying because the file is an exact copy and so the
   copy has the same hash as the original so should be easy to spot

 - The output isn't stable, even if blame2 had a good reason for not
   assigning lines 1 and 2 to their correct commits, why isn't the same
   true in blame3?

 - Blame3 incorrectly ascribes line 4 to commit 4, when it should have
   remained as it was in blame1 - to commit 3.



Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@xxxxxxxxx
-
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]