I agree that each contribution is being acknowledged and Srikanth has aptly explained it. Just to add
1. Being author of a commit is higher form of acknowledgement than being mentioned in the commit message which github doesn't credit in contributor's name. It's a tiny psychological boost for new contributors :) Git provides special provision for this, why not use it? 2. Preserving extended commit messages is harder in current approach as committers have to rewrite commit messages. @Amareshwari, I checked how git and linux projects handle that. For historical reasons they use Signed-off-by for D.C.O (Developer's Certificate of Origin) issues and for code review credits they use tag "Reviewed-by: Real Name of the person<emailid>" at the end of the commit message. You can do that by giving the command git commit --amend after you have applied the patch. Unfortunately, there is no flag to do that automatically in git. On Sat, Jan 10, 2015 at 10:14 PM, Srikanth Sundarrajan <[email protected]> wrote: > I guess @Ajay's point isn't about the acknowledgement of the contributors, > which I guess is happening without any gaps as @Venkatesh has pointed out. > It is more to do with the potential benefits of the proposed approach. From > what I know, this is widely adopted and is increasingly the norm with git > SCM based projects (including apache projects). Some apache examples for > reference to consider > > https://cwiki.apache.org/confluence/display/BIGTOP/How+to+Contribute > http://deltaspike.apache.org/suggested-git-workflows.html > https://airavata.apache.org/community/how-to-commit-contributed-code.html > > https://cwiki.apache.org/confluence/display/KAFKA/Patch+submission+and+review#Patchsubmissionandreview-Simplecontributorworkflow > > https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-ContributorWorkflow > > +1 for the suggestion. The single biggest reason, I feel that this is > worth considering is that the current approach squashes the commits. > > Regards > Srikanth Sundarrajan > > > Date: Fri, 9 Jan 2015 09:45:43 -0800 > > Subject: Re: [DISCUSS] Alternative flow for committing patches > > From: [email protected] > > To: [email protected] > > > > Due credit is given to all contributors in the current approach and we > make > > sure contributor names are added in the commit message. I do not see what > > is the issue? > > > > On Fri, Jan 9, 2015 at 3:28 AM, Ajay Yadav <[email protected]> wrote: > > > > > Hi, > > > > > > Currently when we commit a patch, the git commit shows the commit in > the > > > name of the person who committed the patch to the trunk(committer) and > by > > > convention the committer mentions the name of the person who > contributed > > > the patch(contributor) in the commit message. Committers also need to > make > > > changes to CHANGES.txt to log the change for release notes etc. Git > has a > > > provision to distinguish between author(contributor) and the > committer. I > > > would like to propose another approach and hear your thoughts on this. > > > > > > Commit a patch using the following command > > > git am falcon-652-v2.patch > > > > > > If you have reviewed the patch as well then use -s option and git will > > > append Signed-off-by: with your git handle in the extended commit > message. > > > > > > This command uses the commit metadata in the patch to create a commit. > It > > > also adds a metadata of "signed off by" using the handle of the > committer > > > who is applying the patch. This way the commit is in the name of the > > > contributor and sign off is in the name of the committer who committed > the > > > patch. > > > > > > Please note > > > > > > - Contributors will need to *squash* all commits into one before > > > submitting the patch. If a patch consists of two commits, the > command > > > will > > > create two commits in the trunk. *This behaviour is same as in a > github > > > pull request.* > > > - Contributors will need to generate their patches using *git > > > format-patch* command and not using the git diff command. > > > - Contributors will also need to make the changes to CHANGES.txt > > > > > > *Pros:* > > > > > > - Biggest pro of this approach is that author of commit is the > person > > > who contributed this patch (this should compensate for the extra > steps > > > that > > > the contributors need to make). > > > - Commit messages will be more detailed and more relevant. Users > can now > > > add extended commit messages explaining the changes in more details > and > > > they will not be lost. > > > - Will make committing a patch easier for a committer (less in > numbers > > > than contributors). Committers can use this approach to commit > multiple > > > patches in one go. > > > > > > > > > > > > Cheers > > > Ajay Yadava > > > > > > > > > > > -- > > Regards, > > Venkatesh > > > > “Perfection (in design) is achieved not when there is nothing more to > add, > > but rather when there is nothing more to take away.” > > - Antoine de Saint-Exupéry > >
