From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerlando Falauto Date: Mon, 30 Jul 2012 20:21:47 +0200 Subject: [U-Boot] [PATCH 3/7] powerpc/82xx: merge mgcoge.h and mgcoge3ne.h into km82xx.h In-Reply-To: <20120730160753.900A720226A@gemini.denx.de> References: <1343402200-32020-1-git-send-email-gerlando.falauto@keymile.com> <1343402200-32020-4-git-send-email-gerlando.falauto@keymile.com> <20120727173051.018DC203A3C@gemini.denx.de> <50164F3A.6050409@keymile.com> <20120730130014.9CF2B200332@gemini.denx.de> <5016A093.6040102@keymile.com> <20120730160753.900A720226A@gemini.denx.de> Message-ID: <5016D0BB.3010000@keymile.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 07/30/2012 06:07 PM, Wolfgang Denk wrote: > 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 -> 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 > Date: Mon, 30 Jul 2012 17:57:53 +0200 > Subject: [PATCH] test 1 > > Signed-off-by: Wolfgang Denk > --- > 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