Subject: Re: linux-next: acpi/cpus4096 merge conflict

From: Mike Travis <[email-masked]>
Date: Thu, 12 Jun 2008 11:31:16 -0700

Stephen Rothwell wrote:
> Hi Ingo,
> 
> On Thu, 12 Jun 2008 14:18:24 +0200 Ingo Molnar <[email-masked]> wrote:
>> * Len Brown <[email-masked]> wrote:
>>
>>>> Today's linux-next merge of the acpi tree got a trivial conflict in
>>>> drivers/acpi/processor_throttling.c between commit
>>>> 141ad0688adb53094d6f75b39b4b3b0625de0e07 ("acpi: use performance variant
>>>> for_each_cpu_mask_nr") from the cpus4096 tree and commit
>>>> 08a4ab4a5fd58438840524ce22199c6bbd05816f ("ACPI: change processors from
>>>> array to per_cpu variable") from the acpi tree.
>>>>
>>>> It is just a context conflict and I did the obvious fixup.
>>> thanks.
>>>
>>> it would be ideal if the cpus4096 tree didn't scribble on drivers/acpi 
>>> -- though I don't know if partitioning those patches is practical.
>> well, it's a tree-wide API change and thus maintained in a separate 
>> tree.
> 
> Just a suggestion for next time (or this time if you don't mind a bit of
> rearrangement):
> 
> Having now settled the interface changes down you could submit a patch to
> Linus for his current tree that defines next_cpu_nr, cpus_weight_nr and
> for_each_cpu_mask_nr to be next_cpu, cpus_weight and for_each_cpu_mask
> respectively (just as they still will be for NR_CPUS <= 64).  Once that
> has gone in (and I see no reason it wouldn't) you can send the patches
> that only depend on those three interfaces existing to their respective
> subsystem maintainers who will be now be able to apply them to their own
> trees (maybe after merging in Linus' tree).
> 
> This way I don't have ongoing manual merges to do in the -next tree and
> life is easier all round when we come to the next merge window at which
> point the actual new implementations can go in.
> 
> This has been partially done (and more is being done) with dev_name() and
> dev_set_name().
> 

Sounds like a good idea ... I'll try to restructure future patches so the
common code can be pushed separately and has minimal effect on the base code.
Are there any git options to add a "dependency check" to insure that parent
patches are in place?

Thanks,
Mike