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

Scott Wood
2012-10-11T17:16:17Z

On 10/11/2012 11:38:00 AM, Tom Rini wrote:
> On Tue, Oct 09, 2012 at 02:32:08PM -0700, Tom Rini wrote:
> > On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren wrote:
> [snip]
> > > 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'm going to reply to myself, in hopes of clearing things up. We
> don't
> follow the linux-next model, really, I miss-spoke.
>
> History is important. But so is getting the amount of process for the
> size of the project. The other thing is that we're doing simultaneous
> development for both the current release and the next release.
>
> So for the master branch of the master repo, it must never rebase.
> And
> as Wolfgang encourages users to use the custodian repository of
> mainline
> isn't quite up to what they need, custodian repositories must also
> keep
> their master branch un-rebased as much as humanly possible (my rule of
> thumb would be once it's been in the wild for a few days, it's too
> late).
>
> The next branch however can be rebased, as needed.

Why is the next branch any different? Users and custodians will both
be affected by any rebase, just as if a master branch gets rebased.
This hybrid of the Linux approach and what was described in this thread
as the U-Boot approach is worse than consistently doing one or the
other IMHO.

> In the case of post-v2012.10, it will be rebased as we want the
> commit to change how
> ARM and unaligned accesses are handled to be the first thing.

Any particular reason, short of telling people whose patches have
already been accepted that they need to respin them?

> I don't
> think "perfect" "changes A-G were done in repository X against tree Y"
> is the most useful bit of information. When we rebase we may lose
> that
> boards 1/2/3 worked at point Y but we gain change D is when board 2
> broke as part of being merged with other changes.

I don't follow.

-Scott