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 [email protected] From: Jed Brown <[email protected]> To: Michael Blocksome/Rochester/IBM@IBMUS, Cc: [email protected] Date: 01/06/2014 02:50 PM Subject: Re: [mpich-discuss] Use of Signed-off-by in MPICH Michael Blocksome <[email protected]> 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]