[U-Boot] U-Boot git usage model

[Scott Wood <scottwood@freescale.com>]

On 10/09/2012 05:14:23 PM, Stephen Warren wrote:
> On 10/09/2012 03:32 PM, Tom Rini 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.
> 
> I don't quite follow that; linux-next is also purely merge-based. Are
> you referring to the fact that it's re-created every day, and the
> source branches that go into the merge can be rebased if needed?

What's the difference between "re-created every day" and "rebased every  
day"?

> Instead, I think u-boot/next is just a place where patches get
> applied, or branches get merged, before u-boot/master is open to
> accept new patches for the next release. Unless I'm misunderstanding
> it purpose of course...

That was my impression as well.

> Now, having a linux-next style daily merge of u-boot-*/next would be
> pretty awesome.

Not really needed if the main next tree can permanently merge those  
branches.

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

How does merging back down prevent incremental pull requests?

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

That's a rebase.  How is that better than a (likely fast-forward) merge?

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

I thought you said your way was less work? :-)

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

What is the specific improvement in git history as a result of this?

> > Interesting.  As this is more work on the custodians end, what
> > does everyone else say?
> 
> This actually turns out to be less work for custodians if there aren't
> any dependencies between patch series, since whenever you send a pull
> request right now, you do:
> 
> a) Fetch latest upstream.
> b) Rebase onto it.
> c) Send pull request.

That's what I used to do, but recently Wolfgang said no rebases, so I  
merge instead.

> but with the Linux model, you simply:
> 
> a) Send pull request.
> 
> Admittedly the recipient then might need to resolve some merge
> conflicts. However, hopefully people have been planning for these and
> have avoided them.

How do you plan for them and avoid them, and how is that less work that  
what we do now?

It's one thing if a merge conflict comes from multiple pull requests  
being processed at once, but someone submitting a pull request should  
at least make sure that it doesn't conflict with top-of-tree by itself  
(some actual testing of the merge would be good too...).  And to do  
that, you've got to either merge or rebase, not just blindly request a  
pull.

I especially do not want to have to work with some artificially chosen  
old tree as my base.  I also do not want to create a bunch of named  
branches for each

-Scott