Dear Gerlando Falauto,
In message 5016A093.6040102@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@denx.de Date: Mon, 30 Jul 2012 17:57:53 +0200 Subject: [PATCH] test 1
Signed-off-by: Wolfgang Denk wd@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.
$ git --version git version 1.7.1
$ ~/git/bin-wrappers/git --version git version 1.7.11.3
Could you please share what GIT version you're running?
-> git --version git version 1.7.10.4
That's what I get from the normal Fedora 17 installation.
Could you please try applying the patch to your tree (namely 3 and 4), and then build it again by running: git-format-patch -M30% -C
See above...
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.
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.
Best regards,
Wolfgang Denk