[U-Boot] Non-trivial merge conflicts between u-boot/master and u-boot-arm/master

Gerhard Sittig gsi at denx.de
Sun Nov 10 18:52:08 CET 2013


On Sat, Nov 09, 2013 at 14:50 -0500, Tom Rini wrote:
> 
> On Sat, Nov 09, 2013 at 06:49:01PM +0100, Albert ARIBAUD wrote:
> > 
> > Which 'not-a-diff-exactly' do you mean?
> 
> Well, for example 'git show c0bb110' shows how
> arch/blackfin/cpu/Makefile was merged as a conflict I had to fixup.  The
> ' -' lines are how the blackfin tree was, the ' +' lines are how master
> was and '- ' is what came out from the blackfin side and '++' is what
> came in with my resolution (saved to master) (the '  ' lines are common
> to both).  It's not a diff exactly but it's understandable.

I would not call it "not a diff exactly".  Instead I always
thought of it as "two diffs in one".  You get this representation
upon 'git diff' in rebase conflicts before they are resolved as
well (which are just merges, too).

Consider the two first characters on each line as as "the diff
you introduce" (leftmost column) and "the diff of the conflicting
upstream patch" (second column).  So you can derive whether your
local change follows the upstream's direction ("flows with it")
or is contrary and needs re-consideration (re-introduces what has
gone, or uses what no longer is there).

Applying this interpretation to the 'git show c0bb110' you cite
above, the upstream does s/COBJ/obj/ (plus some more) for most of
the Makefile and you do s/CONFIG_ADI_GPIO1/y/ for gpio.o, while
both changes work towards Kbuild style.  Does this mental model
of mine fit what's happening?  Or am I missing something, or
misinterpreting?


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de


More information about the U-Boot mailing list