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

[Scott Wood]

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