[U-Boot] [PATCH 3/7] powerpc/82xx: merge mgcoge.h and mgcoge3ne.h into km82xx.h

[Gerlando Falauto]

On 07/30/2012 06:07 PM, Wolfgang Denk wrote:
> Dear Gerlando Falauto,
>
> In message<5016A093.6040102 at keymile.com>  you wrote:
>>
>> The way I understand it, such renaming information is built on the fly
>> while building the patch (like you're suggesting, it's a parameter to
>> git format-patch, not to the commit itself).
>
> Yes, and I fail to understand where your problems could be.
>
>> However, I've been struggling to get this same kind of message through
>> git-format-patch. No way, I don't know why. I tried with -M, -M -C,
>> -M10%, adding "[diff]\n renames = copies" to ~/.gitconfig, with both
>> versions below, nothing. Detected as a rename at commit time, it's a
>> plain delete/create commit at patch creation time.
>
> I see this (doing it all manually for testing):
>
> ->  patch -p1</tmp/patch
> ->  git rm include/configs/mgcoge.h include/configs/mgcoge3ne.h
> ->  git add include/configs/km82xx.h
> ->  git commit -s -m 'test 1'
> ->  git format-patch -M -C --stdout HEAD^>/tmp/patch
> ->  less /tmp/patch
>  From 1d9ce92a542d139b78291fb4e437e538d647d55b Mon Sep 17 00:00:00 2001
> From: Wolfgang Denk<wd at denx.de>
> Date: Mon, 30 Jul 2012 17:57:53 +0200
> Subject: [PATCH] test 1
>
> Signed-off-by: Wolfgang Denk<wd at denx.de>
> ---
>   include/configs/{mgcoge3ne.h =>  km82xx.h} |   95 ++++++++++++++++++++++-------
>   include/configs/mgcoge.h                  |   93 ----------------------------
>   2 files changed, 74 insertions(+), 114 deletions(-)
>   rename include/configs/{mgcoge3ne.h =>  km82xx.h} (55%)
>   delete mode 100644 include/configs/mgcoge.h
>
> ...
>
> Oops, I forgot to "git add boards.cfg" here, but for this test it
> makes no difference.

It turns out it's a bug/limitation of git 1.7.1.
I upgraded to 1.7.10.4 and 1.7.11.3 and now I get the same results as 
you do (rename detected). See new patch as a follow-up.

[...]

>> In any case, I have no clue whether git would be able to correctly (i.e.
>> intelligently) apply such patch to a slightly different tree (e.g.
>> through cherry-pick or rebase).
>> So for instance, in your example above, what if file.1 (whose contents
>> is anyway moved into file.common, regardless of rename detection) is
>> slightly different?
>
> It doesn't matter.  If there are conflicts, and these can be resolved,
> it works just the same.
>
>> I'm strongly convinced that if we want to track such changes for what
>> they are (code moving) so that they can be "easily" re-applied, we
>> should mark this explicitly. Even at the cost of creating multiple
>> patches if necessary. Since git isn't able to figure it out by itself,
>
> No, on contrary.  This is basicly an atomic change, and we should not
> artificially split it.  git should have no problems with such actions,
> they are really not special in any way.

Renaming, I understand. But merging/splitting files, I guess they should 
be treated differently (i.e., as such!) IMHO, if we want repeatability 
and resilience to small changes.
But git doesn't (yet?) do that, and I think it should be worked around 
some other way.

>
>> the only way I can think of doing this is splitting the commit into 3 parts:
>
> No, please don't.
>
>> Since mgcoge and mgcoge3ne are the only km82xx boards, there is no
>> need to keep them as separate .h config files.
>> Therefore, make mgcoge3ne.h and mgcoge.h converge into a single
>> km82xx.h file.
>> Step 2 of 3: substitute include files through the following script:
>>
>> INCLUDE_STMT='#include "mgcoge.h"'
>> INCLUDED=include/configs/mgcoge.h
>> INCLUDING=include/configs/km82xx.h
>
> Argh.... No, this is not what we're going to do.

Alright, your call.

Thanks for your patience.
Gerlando