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

[Wolfgang Denk]

Dear Albert,

In message <20120903200244.2ddad7d4 at lilith> you wrote:
> 
> > 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?

Yes, and this is the same.

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

I seriously dislike this for the master branch.

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

Define "official".  Wepublicly announce the existence of ht ecustodian
repositories, and in many cases when you need current code the way to
the custodian repo is the most direct one.

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

But merging keeps all the history in place, i. e. you can always refer
to any specific "old" commit ID, and be sure that it is what you
really refer to because it is secured by cryptographically strong
checksums.

By rebasing, you lose all this history.  Even if you manage to find a
commit that "looks" the same judging from the commit message etc., you
have no guarantee that it's really the same code.

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

Please feel free to do this in working branches.  But I would really
appreciate it if we could stop rebasing any "master" branches.

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

Not sometimes.  I _always_ use "git pull". 

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
In Nature there are neither rewards nor punishments, there are conse-
quences.                                            -- R.G. Ingersoll