[U-Boot] ARM Workflow: rebase on ARM repositories

[Stefano Babic <sbabic@denx.de>]

On 03/09/2012 15:13, Stefan Roese wrote:
> Hi Stefano,
> 
> On 09/03/2012 02:36 PM, Stefano Babic wrote:
>> I was thinking about the way we are usual to manage our trees. This
>> comes because I know about issues from users who set their development
>> on ARM-repositories.
>>
>> One of them uses u-boot-imx for his development, and of course after I
>> rebased my tree he got into trouble, due to using a commit that does not
>> exist anymore.
>> Nevertheless there are boards, where the official documentation explain
>> how to set patches on bases of u-boot-arm. For example,
>>
>> 	http://www.ti.com/tool/tmdsevm3530
>>
>> Detlev discovers that the official documentation refers directly to
>> commit cf6ec699a6dc21a538b039a0392cd38132072090 in u-boot-arm. After a
>> rebase this commit does not exist anymore.
>>
>> Of course, we can really say that setting a development on a ARM
>> repository instead of main repository is not the best ;-). But we know
>> that sometimes setting on a partial repository is the best because some
>> patches that are strictly required are already merged. And I do not know
>> if we can say that our trees are "private" or "development" only: they
>> are published, and available for everybody.
>>
>> Albert has described the way we are currently using in
>> http://www.denx.de/wiki/view/U-Boot/CustodianGitTrees. I think you konow
>> very well and it is the way we follow, and we usually rebase our tree
>> after u-boot-arm is merged by Wolgang in mainline. I want to discuss
>> here if we really need it and if this is the correct way to do.
>>
>> In Linux, every maintainer makes a "git pull" from Linus' tree. Nobody
>> rebases, and I had never had the problem that my tree diverges when I
>> update my kernel's trees from a mainatiner tree. However, this happens
>> continuosly for the users of u-boot-imx. The way we are following  can
>> be seen in the linux-next trees, not in the main trees.
>>
>> The worst thing I think is that we lose the history of our tree, and the
>> behavior can be different. Rebased patches can be different, and testing
>> done until the rebase can be worthless and should be (theoretically)
>> done again. Testers can say they have successfully test a patch, but it
>> was on a pre-rebased tree. A tested-by in a rebased tree can be worthless.
>>
>> My big question is if we should not to come back using "git pull" to
>> downstream mainline from Wolfgang's tree, instead of continuos rebase. I
>> know that we switched to rebase to avoid a lot of "git merge commits",
>> but maybe this is not so bad as rebasing.
>>
>> What is your opinion ?
> 
> I'm quite astonished about this rebasing you mention here. I'm not an
> RAM custodian, so thats probably why I was not aware of it. But I do
> manage 3 U-Boot custodian repositories (non-ARM). And I can't remember
> that I had to rebase my custodian repositories ever. My workflow is the
> one you describe with "git pull" based on Wolfgangs mainline tree. And
> this definitely should be preferred over rebasing.
> 
> Aren't those merge problems solvable without rebasing in the ARM trees?

This is what is done in Linux - I wonder that we do differently.

Cheers,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================