Jeff King <peff@xxxxxxxx> 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:
---A---B---C
\ \
E---F---G---H
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html