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

[Tom Rini]

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?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20121009/bcfc218b/attachment.pgp>