Jiang Xin <[email protected]> writes:
> 2012/7/26 Junio C Hamano <[email protected]>:
>> After stating the observation like the above, please make it a habit
>> to say "which is bad because...", if you think it is a bad behaviour
>> and the patch is about fixing it.
>
> Indead before I start, I examine git-commit and git-am, and find
> the behaviours of the two commands are different.
>
> "git commit -s" checks the last line of the footer, while "git -am"
> checks the last S-o-b.
I think "git am -s" (which I think you meant) is wrong, then.
> E.g. original commit X:
>
> commit log...
>
> Signed-off-by: A
> Signed-off-by: B
> Reported-by: C
The order in this "original" is already wrong, isn't it, though?
Didn't the change result by first C reporting an issue, fixes done
by A and forwarded by B?
> When user B amend the commit, the amended commit Y looks like:
>
> commit log...
>
> Signed-off-by: A
> Signed-off-by: B
> Reported-by: C
> Signed-off-by: B
>
> While if the original commit X send to user B by patch, and
> user B run command "git am -s", the commit would be:
>
> Signed-off-by: A
> Signed-off-by: B
> Reported-by: C
>
> So I guess duplicate S-o-b is not intentional.
I think the two commands are doing randomly different things on
garbage input. The order in the input (i.e. your "original") does
not make sense. C is not the person who handled the patch the last.
If you start from
Reported-by: X
S-o-b: A
Reviewed-by: Y
S-o-b: B
i.e. the last person who touched this patch is B, tweaking the patch
and amending a commit will add S-o-b for the person who amends, iff
that person is not B, which is what you usually want.
> I use an alias for commit:
>
> git config --global alias.ci "commit -s"
>
> And will encounter duplicate S-o-b issues frequently, especially
> format-patch/send-email workflow.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html