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

[Stefan Roese]

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?

Thanks,
Stefan