lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Mon, 9 Jan 2012 09:41:15 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Kukjin Kim <kgene.kim@...sung.com>
Cc:	linux-arm-kernel@...ts.infradead.org,
	linux-samsung-soc@...r.kernel.org, linux-kernel@...r.kernel.org,
	'Marc Zyngier' <marc.zyngier@....com>,
	'Axel Lin' <axel.lin@...il.com>
Subject: Re: [PATCH] ARM: EXYNOS: Fix build error which was from common.c
	and old cpu.c

On Mon, Jan 09, 2012 at 10:27:27AM +0900, Kukjin Kim wrote:
> This fixes build error and wrong merge conflicts.
> arch/arm/mach-exynos/common.c: In function 'exynos4_gic_irq_fix_base':
> arch/arm/mach-exynos/common.c:393: error: dereferencing pointer to incomplete type
> arch/arm/mach-exynos/common.c:396: error: dereferencing pointer to incomplete type
> 
> Following A and B have been created from different base and the build
> error was casued in the process of merging and should be fixed in this
> merge window.
> 
> A. commit db0d4db ("ARM: gic: allow GIC to support non-banked setups"),
>   commit 4e44d2c ("ARM: exynos4: convert to CONFIG_MULTI_IRQ_HANDLER")
>   and commit 69676c3 ("ARM: exynos4: Fix build error due to
>   'gic_bank_offset' undeclared")
> 
> B. commit cc511b8 ("ARM: 7257/1: EXYNOS: introduce arch/arm/mach-exynos/
>   common.[ch]") introduced common.[ch]")

Well, git isn't that good at telling you what conflicts on a delete/modify
conflict - all it does is leave you the modified file in the tree and
expect you to know what changes were made to it between the version which
was deleted, and the modified version.

The various git diff combinations really don't help you either - all you
get told by git is that the file is 'unmerged' and that's it.

I'd say these are the kind of merges which are always going to be full of
errors - and I doubt there's anything which can really be done to stop
them being so (unless git starts marking the file with merge conflict
markers for those changes I describe above.)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists