On Sun, Nov 10, 2013 at 06:52:08PM +0100, Gerhard Sittig wrote:
> 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?Your mental model fits whats happening as well. I just think of it as not a diff exactly since 'patch' would fail :) -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
