* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
