Mailing-List: contact dev-help@falcon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@falcon.apache.org
Received-SPF: pass (athena.apache.org: domain of vseetharam@gmail.com
 designates 209.85.216.42 as permitted sender)
MIME-Version: 1.0
Sender: vseetharam@gmail.com
In-Reply-To: 
 <CAKCPnS5NJRYqCDxF_qbY2RAaM9ek4QS=VhiAF+iyd9pvx91YNw@mail.gmail.com>
References: 
 <CAKCPnS5NJRYqCDxF_qbY2RAaM9ek4QS=VhiAF+iyd9pvx91YNw@mail.gmail.com>
Date: Fri, 9 Jan 2015 09:45:43 -0800
Message-ID: 
 <CAFfn_RqgOqkxipe1+7k0jrm3brhQ+pMzrVotEXvBYPk8fngYcg@mail.gmail.com>
Subject: Re: [DISCUSS] Alternative flow for committing patches
From: Seetharam Venkatesh <venkatesh@innerzeal.com>
To: dev@falcon.apache.org
Content-Type: multipart/alternative; boundary=047d7b6760dec9455a050c3bb9f2

--047d7b6760dec9455a050c3bb9f2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 <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 mak=
e
> 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 th=
e
> 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 githu=
b
>    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 n=
ow
>    add extended commit messages explaining the changes in more details an=
d
>    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 multipl=
e
>    patches in one go.
>
>
>
> Cheers
> Ajay Yadava
>


--=20
Regards,
Venkatesh

=E2=80=9CPerfection (in design) is achieved not when there is nothing more =
to add,
but rather when there is nothing more to take away.=E2=80=9D
- Antoine de Saint-Exup=C3=A9ry

--047d7b6760dec9455a050c3bb9f2--