On 07/30/2012 06:07 PM, Wolfgang Denk wrote:
Dear Gerlando Falauto,
In message5016A093.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 Denkwd@denx.de Date: Mon, 30 Jul 2012 17:57:53 +0200 Subject: [PATCH] test 1
Signed-off-by: Wolfgang Denkwd@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