Re: Announce: Linux-next (Or Andrew's dream :-))

Linus Torvalds
2008-02-12T20:33:20Z

On Tue, 12 Feb 2008, Russell King wrote:
>
> 3. rebase the branch on top of the conflicting change, throw out the
> patches which prove to be a problem and ask the original author of
> those patches to fix them up for the conflicting change. The result
> is a completely bisectable tree.
>
> (3) is the solution which I chose, and it worked _extremely_ well.

Don't get me wrong at all. Rebasing is fine for stuff you have committed
yourself (which I assume was the case here).

Rebasing is also a fine conflict resolution strategy when you try to
basically turn a "big and complex one-time merge conflict" into "multiple
much smaller ones by doing them one commit at a time".

But what rebasing is _not_ is a fine "default strategy", especially if
other people are depending on you.

> (3) is effectively what akpm does with his tree - when a patch conflicts
> with other changes, he throws the changes out and bangs peoples heads
> together to get a new set of patches generated which work together.

Right. And it's one of the fundamental differences between git and a patch
queue.

Patch queues are very flexible, but they simply don't scale. They don't
scale in history (ie you cannot sanely keep track of multiple queues as
they grow in the long run - you need a way to regularly "freeze" things
into a release tar-ball or something like that). But they also don't scale
with number of users - even just read-only ones.

The latter example is something we see in -mm right now. When people
report problems against -mm, it's usually an all-or-nothing thing
(so-and-so mm release doesn't work), but even when people sometimes bisect
to a specific point in mm, it's not "stable" in the sense that that point
may not make any sense in a subsequent -mm queue version.

And all of these issues are not about "-mm" per se, but are about patch
queues in general. And "rebase" turns a git repository effectively to a
patch queue too, with all the same downsides.

And I don't think patch queues are evil: I use git rebase all the time
myself (not for the kernel, but for git, where I'm not the top-level
thing). But I'd not rebase commits from other peoples trees: I rebase
commits that I applied as patches (ie the *author* may be somebody else,
but the committer is me!) or that I committed myself, and that I haven't
pushed out.

Note that difference between "committer" and "author". There's nothing
wrong with rebasing commits that are _authored_ by other people. But there
absolutely is something wrong rebasing commits that are _commmitted_ by
somebody else, unless you two are best buddies and know and trust each
other and are ok with each other messing up the commits (and use some
external method of serialization, so that you don't step on each others
toes).

Linus