falcon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Preece <pre...@yahoo-inc.com.INVALID>
Subject Re: [DISCUSS] Alternative flow for committing patches
Date Fri, 09 Jan 2015 14:46:13 GMT
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 . <amareshwari@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 <ajaynsit@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
>


   
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message