Re: nicer frontend to get rebased tree?

[Andi Kleen <andi@firstfloor.org>]

> Note that the "don't rebase" (as usual) only concerns your published tree. 
> You can certainly rebase non-published stuff.
> 
> As to the "don't base your development on somebody who does" - base your 

That's not practical for me. Maybe it's for you, but it doesn't really
work if you're sufficiently down the food tree. You just have to work
with what other maintainers have and you can't really yell at them
when they do something inconvenient like you do all the time, because
they just ignore you then.

> development either on my tree (I don't rebase) or talk to the d*ck-head 
> that you _want_ to work with, but who rebases.
> 
> > > Remember how I told you that you should never rebase?
> > 
> > I suspect your recommendation does not match real world git use.
> 
> A lot of the trees don't rebase. The rest of the trees may not realize 

That's not my experience, sorry (even on other other trees than linux-next,
linux-next was just an example).  e.g. the original ACPI tree did it,
the x86 tree jungle does it, most of the other architecture trees do it,
the networking tree does it. etc.etc.

Then for linux-next it's reasonable to say that one shouldn't 
do development on top of it, but still if there is supposed
to be a tester base for it it requires at least reasonable
support in git for regular read-only download and right now that
support is at best obscure and unobvious (to avoid stronger words)

> And linux-next has _never_ been appropriate as a development base for 
> other reasons, so forget about linux-next. It's to find merge conflicts 
> and possibly boot/test failures of the trees it contains, not for anything 
> else.

Well it sounds like most people except you get it "wrong". Or maybe
it's more that your intended usage model just does not match what
people really do.

-Andi