What you've said is exactly why we add the "Signed-off by" clause. There are only two pieces of information and therefore all that gets retained is the first (author) and last (committer).

Furthermore, whether or not a cherry-pick is even needed depends on if the "source" branch has been completely rebased  to master or not.  If not, then the commit needs to be changed in the process of moving to master (which resets the committer), but if it is a strict fast-forward of master then the commit is not altered (committer remains the same) and the HEAD pointer of master is merely moved to point to the new commit. If you are trying to have the commiter != author, then you'd have to mess around with the commit in this case.

It seems to me that what you really don't like is the "rebase" style of git workflow and would prefer a "merge" style instead? There are advantages and disadvantages to both - which are well documented in flame wars all across the internet and don't need to be repeated here. Whether some commit says "Signed-off" or "Reviewed" or nothing is really not a big deal - as long as the convention is documented by the community and followed.

Michael Blocksome
Parallel Environment MPI Middleware Team Lead, TCEM
POWER, x86, and Blue Gene HPC Messaging
blocksom@us.ibm.com




From:        Jed Brown <jedbrown@mcs.anl.gov>
To:        Michael Blocksome/Rochester/IBM@IBMUS,
Cc:        devel@mpich.org
Date:        01/06/2014 02:50 PM
Subject:        Re: [mpich-discuss] Use of Signed-off-by in MPICH




Michael Blocksome <blocksom@us.ibm.com> writes:

> In our workflow, often the commit is pushed to an ibm review branch, then
> the signer (usually me) does a signed-off cherry-pick to an anl review
> branch and pushes the code to mpich-ibm git repository for ANL to
> integrate. Using "signed off by" is usually much easier than playing git
> games to ensure that the author and committer are different.

When you cherry-pick, rebase, or amend, Committer will be automatically
reset; no "games".  The problem with that is there are only two pieces
of information (Author and Committer), so if Pavan (for example)
cherry-picks from your branch, the semantic information that you were a
middle-man would be lost [1].  If that semantic information is about
review rather than IP, I would use Reviewed-by instead of Signed-off-by,
but whatever the convention is/becomes, documentation and consistency is
helpful.


[1] If he merges from your branch instead of cherry-picking, then your
commit does not get rewritten and his name would be on the merge commit.
[attachment "attbohle.dat" deleted by Michael Blocksome/Rochester/IBM]