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

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

[Albert ARIBAUD]

Hello,

While preparing my pull request from ARM to mainline, I've tried a
merge of u-boot-arm/master and u-boot/master and had to solve a few
non-trivial conflicts due to the kbuild stuff.

I wonder how I should proceed now. Should I simply submit the PR and
warn Tom that conflicts will arise, and indicate how I solved them?
I'd do (and I've done) that for trivial cases, but for non-trivial
changes it seems error-prone.

Plus, I have already performed the resolutions, so why waster Tom's
time? I could forward u-boot-arm/master to the merge commit, then
submit a fast-forward PR to u-boot/master.

But then, the changes I did will remain un-reviewed or maybe even
unnoticed.

I also thought I could treat this as a normal patch and submit it to the
ML... Only git won't generate a "patch" for merge commits, and I don't
know how patchwork will react to this.

So... any advice?

Amicalement,
-- 
Albert.

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

[Tom Rini]

On Sat, Nov 09, 2013 at 02:11:15PM +0100, Albert ARIBAUD wrote:
> Hello,
> 
> While preparing my pull request from ARM to mainline, I've tried a
> merge of u-boot-arm/master and u-boot/master and had to solve a few
> non-trivial conflicts due to the kbuild stuff.
> 
> I wonder how I should proceed now. Should I simply submit the PR and
> warn Tom that conflicts will arise, and indicate how I solved them?
> I'd do (and I've done) that for trivial cases, but for non-trivial
> changes it seems error-prone.
> 
> Plus, I have already performed the resolutions, so why waster Tom's
> time? I could forward u-boot-arm/master to the merge commit, then
> submit a fast-forward PR to u-boot/master.
> 
> But then, the changes I did will remain un-reviewed or maybe even
> unnoticed.
> 
> I also thought I could treat this as a normal patch and submit it to the
> ML... Only git won't generate a "patch" for merge commits, and I don't
> know how patchwork will react to this.
> 
> So... any advice?

Include the resolution in the PR, and include the not-a-diff-exactly
that git will generate, include that in the PR.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131109/3f6ea9b6/attachment.pgp>

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

[Albert ARIBAUD]

Hi Tom,

On Sat, 9 Nov 2013 11:47:35 -0500, Tom Rini <trini@ti.com> wrote:

> On Sat, Nov 09, 2013 at 02:11:15PM +0100, Albert ARIBAUD wrote:
> > Hello,
> > 
> > While preparing my pull request from ARM to mainline, I've tried a
> > merge of u-boot-arm/master and u-boot/master and had to solve a few
> > non-trivial conflicts due to the kbuild stuff.
> > 
> > I wonder how I should proceed now. Should I simply submit the PR and
> > warn Tom that conflicts will arise, and indicate how I solved them?
> > I'd do (and I've done) that for trivial cases, but for non-trivial
> > changes it seems error-prone.
> > 
> > Plus, I have already performed the resolutions, so why waster Tom's
> > time? I could forward u-boot-arm/master to the merge commit, then
> > submit a fast-forward PR to u-boot/master.
> > 
> > But then, the changes I did will remain un-reviewed or maybe even
> > unnoticed.
> > 
> > I also thought I could treat this as a normal patch and submit it to the
> > ML... Only git won't generate a "patch" for merge commits, and I don't
> > know how patchwork will react to this.
> > 
> > So... any advice?
> 
> Include the resolution in the PR, and include the not-a-diff-exactly
> that git will generate, include that in the PR.

Which 'not-a-diff-exactly' do you mean?

Amicalement,
-- 
Albert.

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

[Tom Rini]

On Sat, Nov 09, 2013 at 06:49:01PM +0100, Albert ARIBAUD wrote:
> Hi Tom,
> 
> On Sat, 9 Nov 2013 11:47:35 -0500, Tom Rini <trini@ti.com> wrote:
> 
> > On Sat, Nov 09, 2013 at 02:11:15PM +0100, Albert ARIBAUD wrote:
> > > Hello,
> > > 
> > > While preparing my pull request from ARM to mainline, I've tried a
> > > merge of u-boot-arm/master and u-boot/master and had to solve a few
> > > non-trivial conflicts due to the kbuild stuff.
> > > 
> > > I wonder how I should proceed now. Should I simply submit the PR and
> > > warn Tom that conflicts will arise, and indicate how I solved them?
> > > I'd do (and I've done) that for trivial cases, but for non-trivial
> > > changes it seems error-prone.
> > > 
> > > Plus, I have already performed the resolutions, so why waster Tom's
> > > time? I could forward u-boot-arm/master to the merge commit, then
> > > submit a fast-forward PR to u-boot/master.
> > > 
> > > But then, the changes I did will remain un-reviewed or maybe even
> > > unnoticed.
> > > 
> > > I also thought I could treat this as a normal patch and submit it to the
> > > ML... Only git won't generate a "patch" for merge commits, and I don't
> > > know how patchwork will react to this.
> > > 
> > > So... any advice?
> > 
> > Include the resolution in the PR, and include the not-a-diff-exactly
> > that git will generate, include that in the PR.
> 
> 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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131109/237eeee7/attachment.pgp>

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

[Albert ARIBAUD]

Hi Tom,

On Sat, 9 Nov 2013 14:50:09 -0500, Tom Rini <trini@ti.com> wrote:

> On Sat, Nov 09, 2013 at 06:49:01PM +0100, Albert ARIBAUD wrote:
> > Hi Tom,
> > 
> > On Sat, 9 Nov 2013 11:47:35 -0500, Tom Rini <trini@ti.com> wrote:
> > 
> > > On Sat, Nov 09, 2013 at 02:11:15PM +0100, Albert ARIBAUD wrote:
> > > > Hello,
> > > > 
> > > > While preparing my pull request from ARM to mainline, I've tried a
> > > > merge of u-boot-arm/master and u-boot/master and had to solve a few
> > > > non-trivial conflicts due to the kbuild stuff.
> > > > 
> > > > I wonder how I should proceed now. Should I simply submit the PR and
> > > > warn Tom that conflicts will arise, and indicate how I solved them?
> > > > I'd do (and I've done) that for trivial cases, but for non-trivial
> > > > changes it seems error-prone.
> > > > 
> > > > Plus, I have already performed the resolutions, so why waster Tom's
> > > > time? I could forward u-boot-arm/master to the merge commit, then
> > > > submit a fast-forward PR to u-boot/master.
> > > > 
> > > > But then, the changes I did will remain un-reviewed or maybe even
> > > > unnoticed.
> > > > 
> > > > I also thought I could treat this as a normal patch and submit it to the
> > > > ML... Only git won't generate a "patch" for merge commits, and I don't
> > > > know how patchwork will react to this.
> > > > 
> > > > So... any advice?
> > > 
> > > Include the resolution in the PR, and include the not-a-diff-exactly
> > > that git will generate, include that in the PR.
> > 
> > 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.

Thanks -- didn't know about 'git show' applied to merge commits. We
live and learn. :)

PR on its way.

Amicalement,
-- 
Albert.

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

[Gerhard Sittig]

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

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

[Tom Rini]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131111/feb21e81/attachment.pgp>

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

[Albert ARIBAUD]

Hi Tom,

On Sat, 9 Nov 2013 11:47:35 -0500, Tom Rini <trini@ti.com> wrote:

> On Sat, Nov 09, 2013 at 02:11:15PM +0100, Albert ARIBAUD wrote:
> > Hello,
> > 
> > While preparing my pull request from ARM to mainline, I've tried a
> > merge of u-boot-arm/master and u-boot/master and had to solve a few
> > non-trivial conflicts due to the kbuild stuff.
> > 
> > I wonder how I should proceed now. Should I simply submit the PR and
> > warn Tom that conflicts will arise, and indicate how I solved them?
> > I'd do (and I've done) that for trivial cases, but for non-trivial
> > changes it seems error-prone.
> > 
> > Plus, I have already performed the resolutions, so why waster Tom's
> > time? I could forward u-boot-arm/master to the merge commit, then
> > submit a fast-forward PR to u-boot/master.
> > 
> > But then, the changes I did will remain un-reviewed or maybe even
> > unnoticed.
> > 
> > I also thought I could treat this as a normal patch and submit it to the
> > ML... Only git won't generate a "patch" for merge commits, and I don't
> > know how patchwork will react to this.
> > 
> > So... any advice?
> 
> Include the resolution in the PR, and include the not-a-diff-exactly
> that git will generate, include that in the PR.

BTW, by 'include the resolution in the PR', I assume you mean 'merge the
mainline master branch into the ARM branch (thus creating a merge
commit at the top of ARM master) then PR this to mainline'. Correct?

Amicalement,
-- 
Albert.

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

[Tom Rini]

On Sat, Nov 09, 2013 at 09:57:25PM +0100, Albert ARIBAUD wrote:
> Hi Tom,
> 
> On Sat, 9 Nov 2013 11:47:35 -0500, Tom Rini <trini@ti.com> wrote:
> 
> > On Sat, Nov 09, 2013 at 02:11:15PM +0100, Albert ARIBAUD wrote:
> > > Hello,
> > > 
> > > While preparing my pull request from ARM to mainline, I've tried a
> > > merge of u-boot-arm/master and u-boot/master and had to solve a few
> > > non-trivial conflicts due to the kbuild stuff.
> > > 
> > > I wonder how I should proceed now. Should I simply submit the PR and
> > > warn Tom that conflicts will arise, and indicate how I solved them?
> > > I'd do (and I've done) that for trivial cases, but for non-trivial
> > > changes it seems error-prone.
> > > 
> > > Plus, I have already performed the resolutions, so why waster Tom's
> > > time? I could forward u-boot-arm/master to the merge commit, then
> > > submit a fast-forward PR to u-boot/master.
> > > 
> > > But then, the changes I did will remain un-reviewed or maybe even
> > > unnoticed.
> > > 
> > > I also thought I could treat this as a normal patch and submit it to the
> > > ML... Only git won't generate a "patch" for merge commits, and I don't
> > > know how patchwork will react to this.
> > > 
> > > So... any advice?
> > 
> > Include the resolution in the PR, and include the not-a-diff-exactly
> > that git will generate, include that in the PR.
> 
> BTW, by 'include the resolution in the PR', I assume you mean 'merge the
> mainline master branch into the ARM branch (thus creating a merge
> commit at the top of ARM master) then PR this to mainline'. Correct?

Right.  I don't mind doing the resolution myself either, but since
you've already done it and done some testing, we should use it :)

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131109/0856c5ef/attachment.pgp>