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

[Stefano Babic]

Am 03/09/2012 20:02, schrieb Albert ARIBAUD:
> Hi Stefano,
> 

Hi Albert,


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

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?

I have not found this issue myself - Detlev discovers that in the
documentation for the bootloader (I think inside the SDK that can be
download following the link in that page) there is an a reference to a
commit-id in u-boot-arm.

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

This is a point - I have also considered that the architecture trees are
unofficial, and users should clone their tree from Wolfgang's tree.

Nevertheless, all these tree are published, and nobody says that they
cannot be used. And they look like as the architecture trees for linux
(linux-omap, linux-imx,...). They also are not rebased and it is not
unusual to get the last status for an architecture from one of these trees.

> 
> 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; :)

Right, this is true.

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

To extend this with the behavior in Linux, this is the link of Jonathan
Corbet's article on lvm:

 http://lwn.net/Articles/328436/

So there are in both cases advantages and drawbacks - the issue is which
is the more suitable for our project. I tend to avoid rebasing due to
the fact that I should not consider u-boot-imx my private and hidden
branch, but a public repository.

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

Of course ;-)


Regards,
Stefano

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