Jeff King <p...@peff.net> 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)
> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html