From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerlando Falauto Date: Mon, 30 Jul 2012 11:09:14 +0200 Subject: [U-Boot] [PATCH 3/7] powerpc/82xx: merge mgcoge.h and mgcoge3ne.h into km82xx.h In-Reply-To: <20120727173051.018DC203A3C@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> Message-ID: <50164F3A.6050409@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 Dear Wolgfang Denk, On 07/27/2012 07:30 PM, Wolfgang Denk wrote: > Dear Gerlando Falauto, > > In message<1343402200-32020-4-git-send-email-gerlando.falauto@keymile.com> you wrote: >> 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. >> >> Signed-off-by: Gerlando Falauto >> --- >> boards.cfg | 4 +- >> include/configs/km82xx.h | 149 +++++++++++++++++++++++++++++++++++++++++++ >> include/configs/mgcoge.h | 93 --------------------------- >> include/configs/mgcoge3ne.h | 93 --------------------------- >> 4 files changed, 151 insertions(+), 188 deletions(-) >> create mode 100644 include/configs/km82xx.h >> delete mode 100644 include/configs/mgcoge.h >> delete mode 100644 include/configs/mgcoge3ne.h > > Can you please try creating this patch with git format-patch with > options "-M" and "-C", please? I think git should do better to > recognize this rename / merge of two files. I tried this but to no avail, the resulting patch is still the same. Same for patch number 4. I guess git gets confused by the fact that we are merging two files into one. What I could do is to split this commit so that, for instance, first we rename one of the files and then (on a separate commit) we move the content of one into the other. In any case, I believe git has no notion of operations like "a file being embedded into another". I think the best we could do is to put such changes into a separate commit and mark it explicitly (perhaps including a sed script in the commit message) so that they can be automated in case of a rebase. Question is, is this really worth the effort? Is there a common practice for such reworks? Thank you, Gerlando