On 07/30/2012 06:07 PM, Wolfgang Denk wrote:
Dear Gerlando Falauto,
In message<5016a093.6040...@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<w...@denx.de>
Date: Mon, 30 Jul 2012 17:57:53 +0200
Subject: [PATCH] test 1
Signed-off-by: Wolfgang Denk<w...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
