[U-Boot] Pull request: u-boot-tegra/master

[Stephen Warren]

On 12/09/2011 08:36 AM, Albert ARIBAUD wrote:
> Hi Stephen,
> 
> Le 08/12/2011 17:45, Stephen Warren a écrit :
>> On 12/08/2011 12:22 AM, Albert ARIBAUD wrote:
>>> Hi Tom,
>>>
>>> Le 08/12/2011 00:35, Tom Warren a écrit :
>>>
>>>> Albert,
>>>>
>>>> This is my first pull request for u-boot-tegra. Let me know if I’ve
>>>> screwed it up in any way!
>>>
>>> Actually:
>>>
>>>> The following changes since commit 3865b6eba83707e1ad134bd42da426fd032948f5:
>>>>
>>>> MX35: flea3: changes due to hardware revision B (2011-12-05 18:31:20 +0100)
>>>
>>> ... This is not the current u-boot-arm/master branch tip, and rebasing
>>> on it fails. Please rebase your master branch on top of
>>> u-boot-arm/master ("davinci: Remove unwanted memsize.c from hawkboard's
>>> nand spl build", commit id 15422043c4a213dc5d7d59a337be1ab34c9b2e7f)
>>> then post a new pull request.
>>
>> Albert,
>>
>> Given that u-boot-arm/master is continually rebased, how would Tom avoid
>> the following, which I think is what happened:
>>
>> 1) pull u-boot-arm/master
>> 2) apply patches to it
>> 3) test
>> 4) send pull request
>>
>> ... while between (1) and (4), you've rebased u-boot-arm/master?
>>
>> I think in the Linux kernel world, this is avoided by having downstream
>> branches based on stable branches in Linus' tree rather than directly
>> on their upstream. This will still allow pull/merge to work fine, but
>> means that there's never a time window that can invalidate the baseline
>> the pull requests are based on.
>>
>> Would something like this work for U-Boot too?
>>
>> Or perhaps, u-boot-arm could publish a stable branch for downstream to
>> base on, yet allow the rest of master to be rebased as needed?
> 
> Note: the rules I follow for pulling requests to u-boot-arm/master are 
> actually those applying to u-boot/master, so I guess the issue you are 
> raising with u-boot-arm could occur with u-boot/master as well -- it 
> moves just like u-boot-arm does, after all.

Doesn't u-boot/master only move forward by merges, whereas
u-boot-arm/master move forward by rebases?

When the base branch moves forward with merges, there's no issue, since
the point the child branch was branched from always exists in the
history of the parent branch, so "git merge" always knows what to use as
the base of the 3-way merge.

With rebases, the history the child branch is based upon no longer
exists in the parent.

> That being said, I do not reject pull requests solely because they are 
> not based on current u-boot-arm/master, precisely because I know it is a 
> moving target at times. So if the request is not based on top of 
> u-boot-arm/master, I try a rebase myself and if it succeeds trivially 
> and I feel confident that there will be no interaction with the commits 
> I've added in between, then I just accept the (now rebased) pull request 
> -- this I have just done again a few days ago. If the pull request does 
> not rebase trivially, then I ask the submitter to rebase because he's 
> the best person to understand and solve the rebase conflict.
> 
> I believe this matches the intent of what you are proposing, but anyway, 
> Wolfgang has the last word -- as usual. :)

OK, there would most likely be the same merge conflicts with merging
rather than rebasing (although I think the 3-way merge process might be
easier to resolve than the rebase process), and so I suppose you'd end
up rejecting the merge request too. That's seems somewhat different to
the kernel process, hence my quest for understanding!

-- 
nvpublic