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

[Albert ARIBAUD]

Hi Stefano,

On Mon, 03 Sep 2012 14:36:31 +0200, Stefano Babic <sbabic at denx.de>
wrote:

> Hi all ARM Custodians,
> 
> 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.

You mean a commit ID that does not exist any more, right?

> 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

I haven't found where in the page a reference to u-boot-arm was made.
Can you clarify this?

> Detlev discovers that the official documentation refers directly to
> commit cf6ec699a6dc21a538b039a0392cd38132072090 in u-boot-arm. After a
> rebase this commit does not exist anymore.

That can happen indeed. I *do* hope that the commit was also described
by its (invariant) commit summary.

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

But they are not official. The official release is u-boot/master.

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

Indeed, but so can it be when the branch is pulled rather than rebased
and fast-forwarded, I believe.

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

This reference;

<http://programmers.stackexchange.com/questions/72632/are-there-any-flaws-with-this-git-branching-model>

(see the detailed answer re merging vs rebasing, and the answer to this
answer) gives us two additional pieces of info:

a) we are not the only project where the opposition between merging and
branching strategies is considered; :)

b) merging requires testing just like rebasing does, which is kind of
evident as for a given pair of branches, both methods yield, or should
yield, the same semantic semantic union of the branches).

My preference goes to rebasing rather than merging because in a
rebasing strategy, each commit in the main branch is a single,
understandable, purposeful change, whereas with merging, if the commit
is a merge, it can be a complete set of pervasive changes which are not
readily identifiable and may serve lots of purposes.

OTOH, we all can see Wolfgang sometimes performing pulls by merging,
so he might have a different view on this.

> Regards,
> Stefano

Amicalement,
-- 
Albert.