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

[Albert ARIBAUD]

Hi Wolfgang,

On Mon, 03 Sep 2012 21:13:28 +0200, Wolfgang Denk <wd at denx.de> wrote:

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

Stefano's reference was about u-boot-arm specifically, and so was my
comment to it. I do agree with you re: the U-Boot master branch (see
below for additional notes)
 
> > > 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.

I consider the official U-Boot to be the one which is used for releases,
and bears labels denoting these. I do not consider official the
architecture trees because -- as per the current rules -- their
custodian may rebase them before a pull request, thus cause the very
trouble Stefano is talking about.

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

Correct.

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

I'll be fine either way. Just note that this policy is at odds with the
documentation at http://www.denx.de/wiki/view/U-Boot/CustodianGitTrees
which suggests rebasing, not merging, masters; the doc should be
changed to match the policy.

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

I guess the occasions where I did not see a merge was when it was
trivialized into a fast-forward, then.

> Best regards,
> 
> Wolfgang Denk

Amicalement,
-- 
Albert.