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,