Git blame only current branch

Hi all-

I'm curious if there's a method to make git blame merge commits that introduce code to the given branch rather than commits on the original (topic) branch?  For example:

  A--B--C---M--D  master
   \       /
    1--2--3       topicA

I'd like a mode where 'git blame master ...' shows commit M for lines changed by topicA so I can easily do 'git blame M^ ...' to see changes (on master) prior to the merge of topicA.  Unfortunately 'git blame master ^topicA ...' blames all the changes of topicA to 3 (which reading the docs appears to be the "correct" behavior).

Thanks!

Stephen

On Mon, Dec 12, 2011 at 10:24:47AM -0500, Stephen Bash wrote:

I'm curious if there's a method to make git blame merge commits that
introduce code to the given branch rather than commits on the original
(topic) branch?  For example:

Usually when you are interested in seeing merges like this in git-log,
you would use one of "--first-parent" or "--merges". However, though
"git blame" takes revision arguments, it does its own traversal of the
graph that does not respect those options.

Modifying it to do --first-parent is pretty easy:

diff --git a/builtin/blame.c b/builtin/blame.c
index 80febbe..c19a8cd 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c

@@ -1191,6 +1191,8 @@ static int num_scapegoats(struct rev_info *revs, struct commit *commit)
 {
 	int cnt;
 	struct commit_list *l = first_scapegoat(revs, commit);
+	if (revs->first_parent_only)
+		return l ? 1 : 0;
 	for (cnt = 0; l; l = l->next)
 		cnt++;
 	return cnt;

With that, "git blame --first-parent" produces reasonable results for
me. But of course I didn't do more than 30 seconds of testing, so it is
entirely possible there are corner cases or unforeseen side effects.

Handling --merges is probably a little trickier, as you need to consider
only some commits as scapegoats, but still traverse through everything
to find the merges.

-Peff

----- Original Message -----

From: "Jeff King" <redacted>
Sent: Monday, December 12, 2011 11:55:42 AM
Subject: Re: Git blame only current branch

On Mon, Dec 12, 2011 at 10:24:47AM -0500, Stephen Bash wrote:

quoted

I'm curious if there's a method to make git blame merge commits
that introduce code to the given branch rather than commits on 
the original (topic) branch?  For example:

Usually when you are interested in seeing merges like this in
git-log, you would use one of "--first-parent" or "--merges". 
However, though "git blame" takes revision arguments, it does
its own traversal of the graph that does not respect those 
options.

My first thought was --first-parent, and was disappointed when I didn't find it in the blame documentation :)  I think for my purposes --first-parent is better than --merges because there are non-merge commits on the branch(es) of interest (and thus I think the problem would become ill-posed in the --merges case).

Modifying it to do --first-parent is pretty easy:
... snip ...

That's pretty simple...  I'll try to do a little testing this afternoon.

Thanks!
Stephen

On 12.12.2011 18:05 Stephen Bash wrote:

 ----- Original Message -----

quoted

From: "Jeff King" <redacted> Sent: Monday, December 12, 2011
11:55:42 AM Subject: Re: Git blame only current branch

On Mon, Dec 12, 2011 at 10:24:47AM -0500, Stephen Bash wrote:

Usually when you are interested in seeing merges like this in
git-log, you would use one of "--first-parent" or "--merges".
However, though "git blame" takes revision arguments, it does its
own traversal of the graph that does not respect those options.

 My first thought was --first-parent, and was disappointed when I
 didn't find it in the blame documentation :)  I think for my purposes
 --first-parent is better than --merges because there are non-merge
 commits on the branch(es) of interest (and thus I think the problem
 would become ill-posed in the --merges case).

quoted

Modifying it to do --first-parent is pretty easy: ... snip ...

 That's pretty simple...  I'll try to do a little testing this
 afternoon.

You might need to consider that if the master branch was first merged 
into topicA before topicA was merged back to the master that the master 
would only be fast-forwarded and so the first parent of M would be 3 not 
C. So depending how the developers merged you might get different results.