Re: git-log --full-history renamed-file
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:42:58
Linus Torvalds [off-list ref] writes:
- it's almost silly, but "git blame" internally really already has all the logic for this, it's just not exposed any sane way to a user. I'm appending a REALLY UGLY patch that makes git blame --log filename.c work kind of like you'd want. IT IS NOT MEANT TO BE REALLY USED, because in particular, it doesn't take the nice log options (so you cannot make it show diffs etc, even though we have all the machinery in place for that). But it's an example of the fact that yes, git can do this, but we're so stupid that we don't really accept it. (NOTE! It's also almost totally untested. It might not work. I'm sending it out as a very rough example, not as a serious contender) Linus
At this point that you call log_tree_commit(),
quoted hunk
@@ -1376,6 +1379,16 @@ static void found_guilty_entry(struct blame_entry *ent) if (ent->guilty) return; ent->guilty = 1; + if (log) { + struct origin *suspect = ent->suspect; + struct commit *commit = suspect->commit; + + if (commit->object.flags & SHOWN) + return; + commit->object.flags |= SHOWN; + log_tree_commit(&log_rev, commit); + return; + }
you have not just the path information _but_ also the line range in the postimage, so we could use an enhanced version of log_tree_commit() that also lets us limit its output only to hunks that touch the affected range. Also, found_guilty_entry() is called number of times for the same suspect <commit, path> pair for discontiguous line ranges. I think a saner thing to do is to collect and coalesce the blame entry for the same <commit, path> in the above part of the code, and then do a single log_tree_commit() for the <commit, path>, perhaps limiting to the hunks that touch the line ranges the commit is assigned blame for, before continuing to a different commit (i.e. after the for() loop, which is the only caller of this found_guilty_entry() function, exits).