From: dmg <dmg@turingmachine.org>
To: git@vger.kernel.org
Subject: behaviour of git-blame -M -C (maybe a bug?)
Date: Thu, 06 Dec 2018 14:41:54 -0800 [thread overview]
Message-ID: <87efau2s7h.fsf@mn.cs.uvic.ca> (raw)
hi everybody,
I am the maintainer of cregit. We are trying to improve blame
traceability at the token level (see
https://github.com/dmgerman/papers/blob/master/editorials/cregit/cregit.org)
We use git-blame heavilty in cregit. One of the features that I
would like to add to cregit is the ability track movement of code.
I have been testing git-blame -M -C and I found some behaviour
that seems incorrect. I have created a very simple repository
that I think showcases this problem:
https://github.com/dmgerman/testBlameMove
this repo have 4 commits (listed below in order of execution):
1. A file is created tpm-dev.c (authored by D German),
2. a refactoring (code is moved from tpm-dev.c to
tpm-dev-common.c, a new file). Author is "refactor"
3. a commit that adds some few contiguous lines (the existence of
this commit seems to matter). Author is "none"
4. a commit that changes few lines and alters the result of blame
for lines not modified by this commit. Author is "problem"
See below. I am running blame at different commits, showing only
the lines attributed to author "refactor" (author of commit #2).
dmg@iodine:/tmp/testRepo|master ⇒ git log --oneline
ded1aa1 (HEAD -> master, origin/master) problematic commit
3720e68 simple commit
391adba refactoring
33165cb file before refactoring
if we checkout 391adba and do blame -M -C we get this:
dmg@iodine:/tmp/testRepo|3720e68 ⇒ git checkout 3720e68 && git
blame -M -C tpm-dev-common.c | grep refactor | head
HEAD is now at 3720e68 simple commit
391adba4 tpm-dev-common.c (refactor 2018-12-06 12:41:10 -0800 24)
begin_include
391adba4 tpm-dev-common.c (refactor 2018-12-06 12:41:10 -0800 25)
include|#
391adba4 tpm-dev-common.c (refactor 2018-12-06 12:41:10 -0800 26)
directive|include
391adba4 tpm-dev-common.c (refactor 2018-12-06 12:41:10 -0800 27)
file|"tpm-dev.h"
391adba4 tpm-dev-common.c (refactor 2018-12-06 12:41:10 -0800 28)
end_include
391adba4 tpm-dev-common.c (refactor 2018-12-06 12:41:10 -0800 147)
DECL|function|tpm_common_open (struct file * file,struct tpm_chip
* chip,struct file_priv * priv)
391adba4 tpm-dev-common.c (refactor 2018-12-06 12:41:10 -0800 148)
name|void
391adba4 tpm-dev-common.c (refactor 2018-12-06 12:41:10 -0800 149)
name|tpm_common_open
391adba4 tpm-dev-common.c (refactor 2018-12-06 12:41:10 -0800 150)
parameter_list|(
391adba4 tpm-dev-common.c (refactor 2018-12-06 12:41:10 -0800 151)
name|struct
so far, so good. blame detects the movement. Note that the changes
by refactor are adding 5 lines (24 to 28) and then adding some at
147 and beyond.
now do it for the next commit: 3720e68
things continue to look good. The changes of this commit do not
affect any of these lines.
now... the next commit, the problematic: ded1aa1 (author is not
refactor)
dmg@iodine:/tmp/testRepo|3720e68 ⇒ git checkout ded1aa1 && git
blame -M -C tpm-dev-common.c | grep refactor | head
Previous HEAD position was 3720e68 simple commit
HEAD is now at ded1aa1 problematic commit
391adba4 tpm-dev-common.c (refactor 2018-12-06 12:41:10 -0800 24)
begin_include
391adba4 tpm-dev-common.c (refactor 2018-12-06 12:41:10 -0800 25)
include|#
391adba4 tpm-dev-common.c (refactor 2018-12-06 12:41:10 -0800 26)
directive|include
391adba4 tpm-dev-common.c (refactor 2018-12-06 12:41:10 -0800 27)
file|"tpm-dev.h"
391adba4 tpm-dev-common.c (refactor 2018-12-06 12:41:10 -0800 28)
end_include
391adba4 tpm-dev-common.c (refactor 2018-12-06 12:41:10 -0800 29)
391adba4 tpm-dev-common.c (refactor 2018-12-06 12:41:10 -0800 30)
begin_function
391adba4 tpm-dev-common.c (refactor 2018-12-06 12:41:10 -0800 53)
name|user_read_timer
391adba4 tpm-dev-common.c (refactor 2018-12-06 12:41:10 -0800 54)
argument_list|)
391adba4 tpm-dev-common.c (refactor 2018-12-06 12:41:10 -0800 150)
DECL|function|tpm_common_open (struct file * file,struct tpm_chip
* chip,struct file_priv * priv)
now blame assigns the lines 29, 30, 53 and 54 to commit 391adba4
refactor!!! This is what I think is a bug.
(by the way, the changes made in this last commit were between 28
and 150)
thank you in advance for any clues on why git-blame is behaving
like this.
--dmg
---
D M German
http://turingmachine.org
reply other threads:[~2018-12-06 22:42 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87efau2s7h.fsf@mn.cs.uvic.ca \
--to=dmg@turingmachine.org \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).