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

[Stephen Warren <swarren@wwwdotorg.org>]

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.

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.