Re: git-log --full-history renamed-file

From: Junio C Hamano <junkio@cox.net>
Date: Mar 10, 2007, 01:59 UTC
Message-ID: <7vejnxzwmp.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0703091339190.10832@woody.linux-foundation.org>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 17 quoted lines

>  - 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(),

Show 14 quoted lines

> @@ -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).