[U-Boot] U-Boot git usage model (was: Re: [PULL] u-boot-usb/next)

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Hi Tom,

On Tue, 9 Oct 2012 14:32:08 -0700, Tom Rini <trini@ti.com> wrote:

> On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren wrote:
> > On 10/09/2012 08:23 AM, Tom Rini wrote:
> > > On Sun, Oct 07, 2012 at 08:49:00PM +0200, Marek Vasut wrote:
> > > 
> > >> NOTE: I get a few more size issues with ELDK 4.2 on IXP (that
> > >> big-endian ARM) after this patchset is applied. I wonder if we
> > >> shouldn't just throw these away, since they're dead code mostly.
> > >> 
> > >> The following changes since commit
> > >> c7ee66a8222660b565e9240775efa4c82cb348c2:
> > >> 
> > >> Merge branch 'next' of git://www.denx.de/git/u-boot-ppc4xx into
> > >> next (2012-10-02 10:16:40 -0700)
> > >> 
> > >> are available in the git repository at:
> > >> 
> > >> 
> > >> git://git.denx.de/u-boot-usb.git next
> > >> 
> > >> for you to fetch changes up to
> > >> f0ede0e8305bc3c959862446bce40cb028b36293:
> > >> 
> > >> usb.h: Add udc_disconnect prototype to usb.h (2012-10-07 02:08:48
> > >> +0200)
> > > 
> > > I had to rebase this locally to merge (such is next), and now it's 
> > > applied to u-boot/next, thanks!
> > 
> > Hmm. Can't "git merge" solve merge conflicts just as well as "git rebase"?
> > 
> > The problem with rebasing when pulling is that git commit IDs change,
> > so it's much more difficult to determine when a commit is merged into
> > a parent tree; one has to search by commit subject rather than just
> > executing e.g. git branch -a --contains XXX. I thought Albert just
> > agreed to use merges rather than rebases for u-boot-arm for this and
> > perhaps other reasons.
> 
> The short answer is that right now, u-boot/next follows the linux-next
> model and we rebase as needed.
> 
> > It would be awesome if U-Boot could adopt something more similar to
> > the Linux kernel's git usage model, namely:
> > 
> > * All downstream branches are based off some known stable point in the
> > master branch (e.g. 2012.10-rc1). Before these branches are merged
> > into any other branch, they can be rebased if absolutely needed, but
> > preferably not.
> > 
> > * Once a downstream branch is merged upwards, the downstream branch
> > doesn't merge upstream back down into the downstream branch, but either:
> > 
> > a) Keeps adding to the existing branch so that incremental pull
> > requests can be sent.
> > 
> > Or often when u-boot/master has made a complete new release does:
> > 
> > b) Creates a new branch based on the latest rc or release from
> > u-boot/master.
> > 
> > (in practice, downstream branches typically end up with something like
> > for-3.5 based on v3.4-rcN, for-3.6 based on v3.5-rcN, for-3.7 based on
> > v3.6-rcN, some running in parallel containing either important
> > bugfixes for the release or new development as determined by the
> > current state of the various releases in the mainline tree).
> > 
> > * When a branch is merged from a repo to a parent repo, it's always a
> > git merge --no-ff; never a rebase or fast-forward.
> > 
> > * In order to resolve merge conflicts/dependencies between different
> > downstream branches, one of the following happens:
> > 
> > 1)
> > 
> > a) The first downstream branch gets merged into u-boot/master.
> > b) The second downstream branch creates a new branch starting at an an
> > rc or release in u-boot-master that contains it the required patches.
> > c) The dependent patches are applied to the second downstream branch.
> > d) The second downstream branch gets merged into u-boot/master.
> > 
> > 2)
> > 
> > All the patches that would usually be merged through downstream branch
> > 2 actually get ack'd by the maintainer of downstream branch 2 and
> > applied to downstream branch 1 after the patches they depend on. This
> > is simplest, but may cause complications if both branches need to take
> > patches that build on the merged patches they're merged into an rc or
> > release in u-boot/master.
> > 
> > 3)
> > 
> > A topic branch is created by one of the downstream maintainers,
> > branched from a u-boot/master rc or release, and containing just the
> > patches that other patches depend on, and this topic branch gets
> > merged into both the two downstream branches for further work.
> > 
> > Yes, this does all take a little bit more thought, planning, and
> > co-ordination, but I think having a simpler and more stable git
> > history is worth it.
> 
> Interesting.  As this is more work on the custodians end, what does
> everyone else say?

IIUC the current rule for U-Boot is that master branches do not rebase
while next branches can (as Tom said).

Apart from this, I'm not sure why forbidding fast-forward is a good
thing, but if there are benefits, why not.

Re merging from upstream back into downstream branches, I tend to think
that must be allowed considering custodian trees are supposed to be
useable, and as such may need to merge back from mainline.

And I am pretty sure we don't need to create branches "for such
version" "based on such version" all the time; keeping each custodian
master current enough should suffice IMO.

Amicalement,
-- 
Albert.