[U-Boot] Non-trivial merge conflicts between u-boot/master and u-boot-arm/master
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,
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.
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,
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.
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,
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
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 :)
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,
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 :)
participants (3)
-
Albert ARIBAUD -
Gerhard Sittig -
Tom Rini