Re: linux-next: x86/cpufreq merge conflict

[Stephen Rothwell <sfr@canb.auug.org.au>]

[-- Attachment #1: Type: text/plain, Size: 1784 bytes --]

Hi Dave,

On Mon, 19 May 2008 18:26:04 -0400 Dave Jones <davej@redhat.com> wrote:
>
> On Mon, May 19, 2008 at 02:39:27PM +1000, Stephen Rothwell wrote:
>  > Hi Dave, Ingo,
>  > 
>  > Today's linux-next cpufreq merge got a conflict in
>  > drivers/cpufreq/cpufreq.c between commit
>  > fdbf6c63c1bd250d45a59a6392fa18ccb360837b ("x86: Use performance variant
>  > for_each_cpu_mask_nr") from the x86 tree and commit
>  > ae47c109341198f814767d2f06a1c1e4c7910fb9 ("[CPUFREQ] change cpu freq
>  > arrays to per_cpu variables") from the cpufreq tree.  The conflict is
>  > just contextual with the former changing for_each_cpu_mask to
>  > for_each_cpu_mask_nr in a couple of places right next to the latter
>  > changing "cpufreq_cpu_data[j]" to "per_cpu(cpufreq_cpu_data, j)".
> 
> ok, so how do we deal with this? Either Ingo or myself will have
> to fix it up depending on whoever merges into .27 first I guess,
> but in the interim, you'll have to carry that diff ?
> Or should one of us drop a diff, and merge both through the other tree?

This conflict appears to have vanished today.  So something changed in
your tree or Ingo's tree.

Normally trivial conflicts like this I can just carry. If they occur
for Linus (when your code goes upstream) he can just fix them up as well.
Also "git rerere" remembers the conflict fix for me and just applies it
again if the conflict reappears.

> btw, I've just slightly changed my workflow for the cpufreq.git tree.
> >From now on, pull from the 'next' branch.   master will be untouched,
> and 'fixes' will be stuff that will go to linus v. soon in the current cycle.

I have updated for today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]