You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@falcon.apache.org by Ajay Yadav <aj...@gmail.com> on 2015/01/09 12:28:15 UTC
[DISCUSS] Alternative flow for committing patches
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
Re: [DISCUSS] Alternative flow for committing patches
Posted by Siva Tumma <si...@gmail.com>.
In my opinion git based pull requests work well.
People with read access to the repo fork, make changes, make pull requests.
The workaround of RAC is either way unavoidable at the committer's (your) end.
The current patch based workaround for me, reduces the interest of contributing.
Thanks for the OpenSource. Any Layman can sound like a professional.
> On 12-Jan-2015, at 11:29 am, Srikanth Sundarrajan <sr...@hotmail.com> wrote:
>
> @Shwetha, Airavat is probably not a good example. You might want to take a look at
>
> https://github.com/apache/kafka/commits/trunk
> https://github.com/apache/knox/commits/master
>
> Commits across multiple pushes wont be interleaved as far as I know.
>
> While we are on this topic, wanted to see if we can use git based pull requests. This will make reviews seamless as well. But we will have to study if this can be done easily. Some projects have moved to this model.
>
> Regards
> Srikanth Sundarrajan
>
>> From: shwethags@gmail.com
>> Date: Mon, 12 Jan 2015 11:19:17 +0530
>> Subject: Re: [DISCUSS] Alternative flow for committing patches
>> To: dev@falcon.apache.org
>>
>> We should maintain single commit per jira. This is useful for multiple
>> reasons:
>> 1. To merge changes between branches, its easier to take commit diff if its
>> single commit. (Its always better to take commit diff than patch on the
>> jira as its possible that patch is out of date or committer made some small
>> changes to the patch before committing.)
>> 2. While debugging issues, to figure out which jira introduced the issue,
>> its useful to look at one commit rather than trying to figure out the diff
>> across commits
>> 3. Looking at commit history, commit message, we can't figure out the jira
>> to which the commit belong to. Since the contributor provides the commit
>> message, you can't enforce particular format. For example, look at commit
>> history of airavata: https://github.com/apache/airavata/commits/master
>> 4. With multiple commits per jira, I think the commits for different jiras
>> will be interleaved which is confusing
>>
>>
>> -Shwetha
>>
>>> On Sun, Jan 11, 2015 at 5:56 AM, Ajay Yadav <aj...@gmail.com> wrote:
>>>
>>> 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 <
>>> sriksun@hotmail.com>
>>> 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: venkatesh@innerzeal.com
>>>>> To: dev@falcon.apache.org
>>>>>
>>>>> 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 <aj...@gmail.com> 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
>
RE: [DISCUSS] Alternative flow for committing patches
Posted by Srikanth Sundarrajan <sr...@hotmail.com>.
@Shwetha, Airavat is probably not a good example. You might want to take a look at
https://github.com/apache/kafka/commits/trunk
https://github.com/apache/knox/commits/master
Commits across multiple pushes wont be interleaved as far as I know.
While we are on this topic, wanted to see if we can use git based pull requests. This will make reviews seamless as well. But we will have to study if this can be done easily. Some projects have moved to this model.
Regards
Srikanth Sundarrajan
> From: shwethags@gmail.com
> Date: Mon, 12 Jan 2015 11:19:17 +0530
> Subject: Re: [DISCUSS] Alternative flow for committing patches
> To: dev@falcon.apache.org
>
> We should maintain single commit per jira. This is useful for multiple
> reasons:
> 1. To merge changes between branches, its easier to take commit diff if its
> single commit. (Its always better to take commit diff than patch on the
> jira as its possible that patch is out of date or committer made some small
> changes to the patch before committing.)
> 2. While debugging issues, to figure out which jira introduced the issue,
> its useful to look at one commit rather than trying to figure out the diff
> across commits
> 3. Looking at commit history, commit message, we can't figure out the jira
> to which the commit belong to. Since the contributor provides the commit
> message, you can't enforce particular format. For example, look at commit
> history of airavata: https://github.com/apache/airavata/commits/master
> 4. With multiple commits per jira, I think the commits for different jiras
> will be interleaved which is confusing
>
>
> -Shwetha
>
> On Sun, Jan 11, 2015 at 5:56 AM, Ajay Yadav <aj...@gmail.com> wrote:
>
> > 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 <
> > sriksun@hotmail.com>
> > 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: venkatesh@innerzeal.com
> > > > To: dev@falcon.apache.org
> > > >
> > > > 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 <aj...@gmail.com> 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
> > >
> > >
> >
Re: [DISCUSS] Alternative flow for committing patches
Posted by Shwetha G S <sh...@gmail.com>.
We should maintain single commit per jira. This is useful for multiple
reasons:
1. To merge changes between branches, its easier to take commit diff if its
single commit. (Its always better to take commit diff than patch on the
jira as its possible that patch is out of date or committer made some small
changes to the patch before committing.)
2. While debugging issues, to figure out which jira introduced the issue,
its useful to look at one commit rather than trying to figure out the diff
across commits
3. Looking at commit history, commit message, we can't figure out the jira
to which the commit belong to. Since the contributor provides the commit
message, you can't enforce particular format. For example, look at commit
history of airavata: https://github.com/apache/airavata/commits/master
4. With multiple commits per jira, I think the commits for different jiras
will be interleaved which is confusing
-Shwetha
On Sun, Jan 11, 2015 at 5:56 AM, Ajay Yadav <aj...@gmail.com> wrote:
> 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 <
> sriksun@hotmail.com>
> 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: venkatesh@innerzeal.com
> > > To: dev@falcon.apache.org
> > >
> > > 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 <aj...@gmail.com> 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
> >
> >
>
Re: [DISCUSS] Alternative flow for committing patches
Posted by Ajay Yadav <aj...@gmail.com>.
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 <sr...@hotmail.com>
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: venkatesh@innerzeal.com
> > To: dev@falcon.apache.org
> >
> > 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 <aj...@gmail.com> 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
>
>
RE: [DISCUSS] Alternative flow for committing patches
Posted by Srikanth Sundarrajan <sr...@hotmail.com>.
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: venkatesh@innerzeal.com
> To: dev@falcon.apache.org
>
> 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 <aj...@gmail.com> 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
Re: [DISCUSS] Alternative flow for committing patches
Posted by Seetharam Venkatesh <ve...@innerzeal.com>.
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 <aj...@gmail.com> 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
Re: [DISCUSS] Alternative flow for committing patches
Posted by Scott Preece <pr...@yahoo-inc.com.INVALID>.
It looks like -s doesn't accept an argument, so you can't add a signoff for a third party.
scott
On Friday, January 9, 2015 5:44 AM, amareshwarisr . <am...@gmail.com> wrote:
Very nice. I really liked it.
Can we pass a reviewer name to -s as well, to say signed off by someone
else?
I see main challenge will be with contributor who didn't follow the patch
generation with format patch/squashing/commit messages. For such patches
fall back to old style?
Thanks
Amareshwari
On Fri, Jan 9, 2015 at 4:58 PM, Ajay Yadav <aj...@gmail.com> 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
>
Re: [DISCUSS] Alternative flow for committing patches
Posted by "amareshwarisr ." <am...@gmail.com>.
Very nice. I really liked it.
Can we pass a reviewer name to -s as well, to say signed off by someone
else?
I see main challenge will be with contributor who didn't follow the patch
generation with format patch/squashing/commit messages. For such patches
fall back to old style?
Thanks
Amareshwari
On Fri, Jan 9, 2015 at 4:58 PM, Ajay Yadav <aj...@gmail.com> 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
>