[U-Boot] U-Boot git usage model

[Graeme Russ]

Hi Tom,

On Wed, Oct 10, 2012 at 9:59 AM, Tom Rini <trini at ti.com> wrote:
> On Tue, Oct 09, 2012 at 04:14:23PM -0600, 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?
>
> I'm referring to that it's always rebased on top of Linus' tree.  That's
> what caused the issue here, u-boot-usb was based on top of u-boot/next
> (which is may not have strictly needed to be) so I did the job of
> rebasing for Marek since it was an easy one.
>
>> 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.
>
> Well, it's a merge of what people want to get into the next merge
> window, as often as they're willing to submit if they are a custodian or
> as often as I can otherwise.  In fact, right now some pull requests need
> to be on top of next rather than a "stable" point because we're making
> some pretty big cleanups and changes in a few areas right now.

I'm no git guru, so this may not be sane, but here goes:

u-boot-master and $(repo)-master are parallel branches - $(repo)
maintainer merges u-boot-master regularly and applies $(repo) specific
patches to $(repo)-master during the merge window (and critical fixes
during the -rc cycle). Tom merges the various $(repo)-master's into
u-boot-master regularly.

u-boot-next and $(repo)-next are also parallel branches. $(repo)
maintainer merges u-boot-master and $(repo)-master regularly and
applies $(repo) specific patches to $(repo)-master during the -rc
cycle. Tom merges the various $(repo)-next's into u-boot-next
regularly.

Immediately following a release, Tom merges u-boot-next into u-boot-master

Yes, we get lots of merge commits, but the strategy is very straightforward...

One thing I don't know how to resolve is what happens when a
$(repo)-{master, next} does not merge cleanly into u-boot-{master,
next}...

Regards,

Graeme