<font size=2 face="sans-serif">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).
</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif"><br>
Michael Blocksome<br>
Parallel Environment MPI Middleware Team Lead, TCEM<br>
POWER, x86, and Blue Gene HPC Messaging<br>
blocksom@us.ibm.com<br>
</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">Jed Brown <jedbrown@mcs.anl.gov></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">Michael Blocksome/Rochester/IBM@IBMUS,
</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:      
 </font><font size=1 face="sans-serif">devel@mpich.org</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">01/06/2014 02:50 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">Re: [mpich-discuss]
Use of Signed-off-by in MPICH</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>Michael Blocksome <blocksom@us.ibm.com> writes:<br>
<br>
> In our workflow, often the commit is pushed to an ibm review branch,
then <br>
> the signer (usually me) does a signed-off cherry-pick to an anl review
<br>
> branch and pushes the code to mpich-ibm git repository for ANL to
<br>
> integrate. Using "signed off by" is usually much easier
than playing git <br>
> games to ensure that the author and committer are different.<br>
<br>
When you cherry-pick, rebase, or amend, Committer will be automatically<br>
reset; no "games".  The problem with that is there are only
two pieces<br>
of information (Author and Committer), so if Pavan (for example)<br>
cherry-picks from your branch, the semantic information that you were a<br>
middle-man would be lost [1].  If that semantic information is about<br>
review rather than IP, I would use Reviewed-by instead of Signed-off-by,<br>
but whatever the convention is/becomes, documentation and consistency is<br>
helpful.<br>
<br>
<br>
[1] If he merges from your branch instead of cherry-picking, then your<br>
commit does not get rewritten and his name would be on the merge commit.<br>
[attachment "attbohle.dat" deleted by Michael Blocksome/Rochester/IBM]
</font></tt>
<br>