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

[Albert ARIBAUD]

Le 09/12/2011 18:10, Stephen Warren a écrit :
> 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?

Well, as per the wiki, u-boot/master should move by rebases, or more 
exactly, by fast-forwards, as pull requests to it should always be 
(re)based on it.

> 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.

If you mean the history of which repo the commit entered initially and 
which one it went through with each merge, that's true. But do we need 
this history?

Note that if the process should change to merges rather than rebases, 
I'm ok with that but I believe it might make bisecting more difficult.

>> 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!

Er... Rebase *does* 3-way merges when necessary and possible. I just saw 
it done while pulling tegra, samsung and imx requests.

Amicalement,
-- 
Albert.