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.
> $ 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
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
All a hacker needs is a tight PUSHJ, a loose pair of UUOs, and a warm
place to shift.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
