Hi Andre,
On Thu, 04 Apr 2013 12:31:08 +0200, Andre Przywara andre.przywara@linaro.org wrote:
On 04/04/2013 12:09 PM, Albert ARIBAUD wrote:
Hi Andre,
On Wed, 3 Apr 2013 15:44:33 +0200, Andre Przywara andre.przywara@linaro.org wrote:
From: Ryan Harkin ryan.harkin@linaro.org
This patch creates a new config for the A9 quad core tile that includes the generic config for the Versatile Express platform.
Signed-off-by: Ryan Harkin ryan.harkin@linaro.org Signed-off-by: Andre Przywara andre.przywara@linaro.org
MAINTAINERS | 2 +- boards.cfg | 2 +- include/configs/vexpress_ca9x4.h | 34 ++++++++++++++++++++++++++++++++++ include/configs/vexpress_common.h | 1 - 4 files changed, 36 insertions(+), 3 deletions(-) create mode 100644 include/configs/vexpress_ca9x4.h
Wait, so patch 1/5 renames ca9x4_ct_vxp as vexpress_common, then patch 2/5 renames vexpress_common as vexpress_ca9x4? If so then please make this a single patch without the intermediary/temporary step.
But that would not mark the actual file copy (vexpress_common.h is almost the same as vexpress_ca9x4.h) as such, right? So you would end up with a completely new file (_common.h) and a file with almost all content deleted (_ca9x4.h). The fact that the code just moved wouldn't be obvious. That would be extra pity with the nice -M move features in the previous patch.
Try -C too, for copies, and possibly --find-copies-harder.
I don't see how eliminating the intermediate target naming would prevent git from detecting moves and copies; and it will simplify the changes undergone by non-header files such as baords.cfg and MAINTAINERS.
However I have no problems with merging these two, if you insist.
I am fine with either of the two following solutions:
a) If patch 1/5 commonalizes vexpress code, then it should not rename any target, and patch 2/5 should do the renaming.
or
b) if patch 1/5 commonalizes and renames the target, it should give it its final name and patch 2 should be merged in.
Regards, Andre.
Amicalement,