Jeff King <> writes:

> diff --git a/builtin/blame.c b/builtin/blame.c
> index 57a487e..0fb67af 100644
> --- a/builtin/blame.c
> +++ b/builtin/blame.c
> @@ -1199,6 +1199,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;
> (though I suspect it would interact oddly with the "--reverse" option,
> and we would want to either declare them mutually exclusive or figure
> out some sane semantics).

It is entirely unclear who the first child is, so I tend to think
that they have to be mutually exclusive.

>> Aside: in some trial and error I notice this oddity:
>>     $ git blame --merges
>>     usage: git blame [options] [rev-opts] [rev] [--] file
>>         [rev-opts] are documented in git-rev-list(1)
>>     ...
> Your problem is not the presence of "--merges" here, but that you forgot
> the necessary "file" argument. Try "git blame --merges foo.c".
> However, this suffers from the same problem as --first-parent, in that
> it is accepted but not respected. Doing so would not be impossible, but
> it is a little more than the two-liner above.

What the command does when it "respects" it is unclear to me.
In a history like this:

    \       \

and starting at H, pretend everything that happened in, B, C, E and
F since A was done by G?  Who gets the blame for what A or H did?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to