On Wed, Sep 12, 2012 at 1:42 PM, Chip Childers <[email protected]> wrote: > On Wed, Sep 12, 2012 at 4:35 PM, Sheng Yang <[email protected]> wrote: >> Hi, >> >> I think we would need some way to make the commit more clear. >> >> Currently committers are committed the patch in any format he/she >> want. E.g. using reviews.apache.org 's ticket number as subject, add >> some "Contributed-by:" or "Sent-by:" or "Wrote-by:" in the context to >> identify the contributor(but committer themselves remained "Author"), >> which is inconsistent across the committers, and hard for statistics. >> >> Also many commits lacks of proper explanation and subjects to be >> easily identified. >> >> So the best way to me, is let contributor listed as Author in the >> commit, and committer can "Signed-off" on it. >> >> I suggest we can follow the Linux Kernel community case on this issue. >> >> 1. the contributor should provide git-format-patch generated patch, >> which is able to indicate who is the author and what's to fix. >> 2. Committer should use git-am to apply the patch, add Signed-off-by: >> xxxx([email protected]) at end of it, to indicate who agreed and >> committed this patch(in fact there are more potential rules here, but >> let's stick with the simplest one first). >> >> Then author need to write the subject and more detail explaining of >> the patch if necessary, and it would be easier for others to track >> which patch is from who on what issue, and what's the solution. >> >> Another advantage/disadvantage of git-am is, it's very strict. You >> have provided up-to-date patch, otherwise it would fail. No fuzz is >> allowed. >> >> One problem currently is reviews.apache.org doesn't accept the git >> formatted patch, it would only accept diff. So if we want to get patch >> from reviews.apache.org, it would result in committer have to find >> subject and detail explanation for the patch, which may varies from >> author's, and also increase committer's workload. >> >> I think probably we can let contributor send out two mail for each >> patch? One attached latest patch, another one which is sent by >> reviews.apache.org, provided a convenient way for reviewing? The >> alternative way of doing is let contributor send out >> git-format-patch-ed patch(which would be based on the latest code) >> after committer reviewed patch and think it's ready to be applied. >> >> --Sheng >> > > Hey Sheng, > > Given the current limits of reviews.a.o, I've recently turned to using > this process: > > git apply foo.patch > git commit -a -s --author='Person Name <[email protected]>' > > Then, I've been putting in the reviewboard summary and description > into the commit comment (sometimes edited to help with clarity), which > should be easily available since the patch was just downloaded from > reviewboard anyway. > > This gives us the correct author, correct committer and a decent commit > message.
Hi Chip, Yes, this works, though still committer need to do some tweak on the patches, and more you do, the more chance you got to mess up something. To me, what's the advantage of git-am is, it would guarantee what's original author wanted information is there, as well as code is intact. Currently I think your approach is good, but we need to make it as a policy and require every committer to do the same as well. > > Personally, I'd like to avoid double emails. We also know that the > dev list both truncates (and sometimes mangles) patches sent in the > text of emails, as well as stripping attachments out. Would the > method I'm describing above work for you? I think it's fine for now, but when volume of patches and workload increase, I suppose we still need to figure out some way more directly. --Sheng > > -chip
