Re: [GIT pull] x86 fixes for 2.6.26
From: Linus Torvalds
Date: Fri May 16 2008 - 23:20:59 EST
On Fri, 16 May 2008, Theodore Tso wrote:
> Why do you consider rebasing topic branches a bad thing?
Rebasing branches is absolutely not a bad thing for individual developers.
But it *is* a bad thing for a subsystem maintainer.
So I would heartily recommend that if you're a "random developer" and
you're never going to have anybody really pull from you and you
*definitely* don't want to pull from other peoples (except the ones that
you consider to be "strictly upstream" from you!), then you should often
plan on keeping your own set of patches as a nice linear regression.
And the best way to do that is very much by rebasing them.
That is, for example, what I do myself with all my git patches, since in
git I'm not the maintainer, but instead send out my changes as emails to
the git mailing list and to Junio.
So for that end-point-developer situation "git rebase" is absolutely the
right thing to do. You can keep your patches nicely up-to-date and always
at the top of your history, and basically use git as an efficient
patch-queue manager that remembers *your* patches, while at the same time
making it possible to efficiently synchronize with a distributed up-stream
So doing "git fetch + git rebase" is *wonderful* if all you keep track of
is your own patches, and nobody else ever cares until they get merged into
somebody elses tree (and quite often, sending the patches by email is a
common situation for this kind of workflow, rather than actually doing git
merges at all!)
So I think 'git rebase' has been a great tool, and is absolutely worth
knowing and using.
*BUT*. And this is a pretty big 'but'.
BUT if you're a subsystem maintainer, and other people are supposed to be
able to pull from you, and you're supposed to merge other peoples work,
then rebasing is a *horrible* workflow.
It's horrible for multiple reasons. The primary one being because nobody
else can depend on your work any more. It can change at any point in time,
so nobody but a temporary tree (like your "linux-next release of the day"
or "-mm of the week" thing) can really pull from you sanely. Because each
time you do a rebase, you'll pull the rug from under them, and they have
to re-do everything they did last time they tried to track your work.
But there's a secondary reason, which is more indirect, but despite that
perhaps even more important, at least in the long run.
If you are a top-level maintainer or an active subsystem, like Ingo or
Thomas are, you are a pretty central person. That means that you'd better
be working on the *assumption* that you personally aren't actually going
to do most of the actual coding (at least not in the long run), but that
your work is to try to vet and merge other peoples patches rather than
primarily to write them yourself.
And that in turn means that you're basically where I am, and where I was
before BK, and that should tell you something. I think a lot of people
are a lot happier with how I can take their work these days than they
were six+ years ago.
So you can either try to drink from the firehose and inevitably be bitched
about because you're holding something up or not giving something the
attention it deserves, or you can try to make sure that you can let others
help you. And you'd better select the "let other people help you", because
otherwise you _will_ burn out. It's not a matter of "if", but of "when".
Now, this isn't a big issue for some subsystems. If you're working in a
pretty isolated area, and you get perhaps one or two patches on average
per day, you can happily basically work like a patch-queue, and then other
peoples patches aren't actually all that different from your own patches,
and you can basically just rebase and work everything by emailing patches
around. Big deal.
But for something like the whole x86 architecture, that's not what te
situation is. The x86 merge isn't "one or two patches per day". It easily
gets a thousand commits or more per release. That's a LOT. It's not quite
as much as the networking layer (counting drivers and general networking
combined), but it's in that kind of ballpark.
And when you're in that kind of ballpark, you should at least think of
yourself as being where I was six+ years ago before BK. You should really
seriously try to make sure that you are *not* the single point of failure,
and you should plan on doing git merges.
And that absolutely *requires* that you not rebase. If you rebase, the
people down-stream from you cannot effectively work with your git tree
directly, and you cannot merge their work and then rebase without SCREWING
UP their work.
And I realize that the x86 tree doesn't do git merges from other
sub-maintaines of x86 stuff, and I think that's a problem waiting to
happen. It's not a problem as long as Ingo and Thomas are on the net every
single day, 12 hours a day, and respond to everything. But speaking from
experience, you can try to do that for a decade, but it won't really work.
I've talked to Ingo about this a bit, and I'm personally fairly convinced
that part of the friction with Ingo has been that micro-management on a
per-patch level. I should know. I used to do it myself. And I still do it,
but now I do it only for really "core" stuff. So now I get involved in
stuff like really core VM locking, or the whole BKL thing, but on the
whole I try to be the anti-thesis of a micro-manager, and just pull from
It's easier for me, but more importantly, it's actually easier for
everybody *else*, as long as we can get the right flow working.
Which is why I still spend time on git, but even more so, why I also try
to spend a fair amount of time on explaining flow issues like this.
Because I want to try to get people on the same page when it comes to how
patches flow - because that makes it easier for *everybody* in the end.
[ IOW, from my personal perspective, in the short run the easiest thing to
do is always "just pull".
But in the long run, I want to know I can pull in the future too, and
part of that means that I try to explain what I expect from downstream,
but part of that also means that I try to push down-stream developers
into directions where I think they'll be more productive and less
stressed out so that they'll hopefully *be* there in the long run.
And I think both Ingo and Thomas would be more produtive and less
stressed out if they could actually pull from some submaintainers of
their own, and try to "spread the load" a bit. It involves them finding
the right people they can trust, but it also involves them having a
workflow in place that _allows_ those kinds of people to then work with
> Is there a write up of what you consider the "proper" git workflow?
See above. It really depends on where in the work-flow you are.
And it very much does depend on just how big the flow of patches is. For
example, during 2.6.24..26, net/ and drivers/net had ~2500 commits.
arch/x86 and include/asm-x86 had ~1300 commits. Those are both big
numbers. We're talking a constant stream of work.
But Ted, when you look at fs/ext4, you had what, 67 commits in the
2.6.24..25 window? That's a whole different ballgame. If you have 67
commits in a release window of two months, we're talking roughly one a
day, and you probably didn't have a single real conflict with anybody else
during that whole release window, did you?
In *that* situation, you don't need to try to stream-line the merging. You
are better off thinking of them as individual patches, and passing them
around as emails on the ext4 mailing lists. People won't burn out from
handling an average of one patch a day, even for long long times. Agreed?
Realistically, not many subsystems really need to try to find
sub-sub-maintainers. Of the architectures, x86 is the most active one
*by*far*. That said, I think PowerPC actually has a chain of maintenance
that is better structured, in that there is more of a network of people
who have their own areas and they pull from each other. And POWERPC only
has about half the number commits that x86 has. I bet that lower number of
commits, coupled with the more spread out maintenance situation makes it
*much* more relaxed for everybody.
Networking, as mentioned, is about twice the number of patches (in
aggregate) from x86, but the network layer too has a multi-layer
maintenance setup, so I suspect that it's actually more relaxed about that
*bigger* flow of commits than arch/x86 is. Of course, that's fairly
recent: David had to change how he works, exactly so that the people who
work with him don't have to jump through hoops in order to synchronize
with his tree.
In other words, I very heavily would suggest that subsystem maintainers -
at least of the bigger subsystems, really see themselves as being in the
same situation I am: rather than doing the work, trying to make it easy
for *others* to do the work, and then just pulling the result.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/