This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Commit procedure question: One commit, or multiple commits.
- From: "Ryan S. Arnold" <ryan dot arnold at gmail dot com>
- To: "Carlos O'Donell" <carlos at systemhalted dot org>
- Cc: libc-alpha at sourceware dot org, Will Schmidt <will_schmidt at vnet dot ibm dot com>
- Date: Tue, 17 Apr 2012 11:53:12 -0500
- Subject: Re: Commit procedure question: One commit, or multiple commits.
- References: <CADZpyiyG8_m+9MkXUbFp6+r195fdkGKZmr-X4saGR4JPVSwGzg@mail.gmail.com>
On Tue, Apr 17, 2012 at 9:57 AM, Carlos O'Donell
<carlos@systemhalted.org> wrote:
> On Tue, Apr 17, 2012 at 10:15 AM, Ryan S. Arnold <ryan.arnold@gmail.com> wrote:
>> I have a question on commit procedure.
>>
>> When a patch set is to be committed which process should be used:
>>
>> 1) Apply all patches locally and commit as a single commit, merging
>> the ChangeLogs.
>>
>> or
>>
>> 2) Apply each patch and commit individually.
>
> Assuming the patches are logically distinct and the tree builds and
> has no regressions between patches.
>
> Then the patch is logically the same as a commit.
>
> Therefore you would do (2).
>
> However, there is the case where it is easier to split a patch into a
> patch set for easier review, but the patches are interdependent and
> would break or regress the testsuite if committed independently.
>
> In that case I would do (1).
>
> The trick is keeping trunk in a buildable regression free state for
> other developers.
Thanks Carlos,
In general I think a series of individual commits comprising a
patch-set would be pushed upstream in a single push so the state of
the tree shouldn't be in danger.
I think for the power7 wordcopy and memmove patch set I'll use option
2. This will require merging the ChangeLogs though.
Ryan