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
