Re: nicer frontend to get rebased tree?

[Ingo Molnar <mingo@elte.hu>]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Sat, 23 Aug 2008, Andi Kleen wrote:
> > > 
> > > 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,

[ thanks for the lovely charecterisation of -tip, it's appreciated.
  </sarcasm> ]

> > the networking tree does it. etc.etc.
> 
> So _complain_ to those people. Tell them that they are making your 
> life harder. Let them know.
> 
> I sure as hell let people know when they are making _my_ life harder. 
> It has helped. The networking tree stopped rebasing, and the x86 tree 
> doesn't do it for the topic branches (although I think it re-creates 
> the "common" branches all the time, kind of like linux-next).

Correct - we keep all topic branches append-only. (We rebase a topic 
only in exceptional cases: if there's a complete restart from scratch, 
when the history is so messy or uninteresting that no-one would care 
about it.)

And we do more than that: even tip/master is becoming more and more 
append-only. We are set up in a way that makes rebasing of a topic 
branch painful for _us_ integrators already. That is because tip/master 
is a "consumer" of all the topic trees, in form of 'delta-integration', 
which just merges all updated topic branches ontop of tip/master.

If a topic tree is rebased, we feel the pain in tip/master: no easy 
delta-integration run is possible anymore, we get a ton of conflicts due 
to the changed sha1's and due to the slightly changed content and the 
whole topic tree has to be undone and re-merged. It's also harder to 
track changes and it's harder to trust the quality of a stream of 
changes if they get rebased - etc.

Alas, we dont rebase when we can avoid it.

We periodically 'reintegrate' the whole thing to create the linux-next 
output branches and to get rid of the uninteresting hundreds of 
criss-cross merges, but that's on a relatively slow scale of 1-2 weeks.

( which is still too frequent for this to be truly append-only, but
  dependable enough for short-term development and obviously good for
  testing and regression-bisection activities. )

When people ask me "what should I use for development, tip/master?", i 
suggest them to use -git or a specific topic branch they are interested 
in. (and each topic branch is based on upstream -git as well.)

Sometimes if they are working in an area where there's known overlap 
with multiple topics, people will send patches/pull-requests against 
tip/master. In that case we maintainers sort those out and 'spread' them 
into individual topic branches - i.e. turn them into an append-only flow 
of changes.

But arch/x86 development is also a bit special: in the past year it has 
gathered almost as many developers and per kernel cycle commits as the 
networking tree, but compressed into a highly critical and hard to 
debug/test ~190 KLOC codebase.

The networking tree is an order of magnitude larger at 1.5 MLOC, which 
makes it statistically a lot less likely that commits would overlap in 
it - and makes it far more feasible to handle conflicts in the simplest 
and most robust way: by doing hierarchical maintenance with strict 
boundaries and thus _avoiding_ conflicts.

Hence we've set up the x86 tree as this 'forest of 160+ trees' which 
topic trees iteract with each other intelligently and which get 
integrated into a single "kitchen sink" test branch, tip/master.

	Ingo