Re: nicer frontend to get rebased tree?

From: Ingo Molnar <mingo@elte.hu>
Date: Aug 25, 2008, 09:36 UTC
Message-ID: <20080825093645.GA7741@elte.hu>
In-Reply-To: <alpine.LFD.1.10.0808231054400.3363@nehalem.linux-foundation.org>

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

Show 7 quoted lines

> 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> ]

Show 9 quoted lines

> > 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