[U-Boot] U-Boot git usage model

[Stephen Warren]

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?

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

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

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

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.

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.

Now, if there are dependencies between branches, then perhaps the
formalized options above seem like more work, but I don't think
there's a good solution in place today for this anyway, is there? So,
it still seems like this simplifies things.