[U-Boot] U-Boot git usage model

[Stephen Warren]

On 10/09/2012 04:59 PM, Tom Rini 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.

So, is u-boot/next purely incremental, or lets say something is merged
in there, then needs to be reworked because of some nasty git bisect
issue say, or some patches need to be taken through different trees
due to dependencies, can the already-merged patches be removed and
replaced with a completely new set, or can only incremental patches be
applied?

I assume u-boot/next isn't rebuilt using fresh merges each time, hence
isn't the linux-next model exactly?