Commit procedure question: One commit, or multiple commits.

[Ryan S. Arnold]

On Tue, Apr 17, 2012 at 11:53 AM, Ryan S. Arnold <ryan.arnold@gmail.com> wrote:
> 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.

This should have said "I'll use option 1."

I just realized a problem with my suggestion about pushing more than a
single commit.  Once the patches are committed locally it precludes
the ability to git pull --rebase to bring the patch set up to the
current head to avoid the merge.

Ryan