[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 at 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>