Re: [alsa-devel] HG -> GIT migration

From: Linus Torvalds
Date: Wed May 21 2008 - 14:12:32 EST

On Wed, 21 May 2008, Linus Torvalds wrote:
> So merging on its own is not "wrong or evil" at all. Merging is a very
> good operation to do, but *mindless* merging is bad. That's really all
> that I'm really trying to argue against.

Btw, let me explain this another way.

I do a *lot* of merges as being an "upstream" person. Since 2.6.25, I've
done something like 247 merges (and that's not counting the fast-forward
ones). If you do

git log v2.6.25.. -author=torvalds

you'll see pretty much just merges. It's simply what I do. I have a few
fairly trivial patches every once in a while (although you almost have to
add a "--no-merges" to filter out the merges to see them), but doing
merges is what I do most.

So why would I tell others to not merge, when I've done several hundred
merges in just the last month myself? Isn't that really hypocritical of

The symmetry breaking comes from a few things:

- the merges that "upstream" people do are generally smaller, but even
when they are large, they have a "theme".

Most merges I do are fairly small, but even when they aren't (eg the
network layer merge of all the thousands of commits that were pending
for when the merge window opened), they are _directed_.

IOW, when upstream does a merge, it's hopefully (if the process works
correctly) going to be about a specific sub-area, even if that area may
be pretty big. So the merge has a very specific meaning: "I want to
pull in the changes to subsystem 'xyz'"

In contrast, a merge that goes the other way (subsystem merging
upstream) generally doesn't get any particular directed development
changes, it just gets "everything else".

This also explains why I can do merge summaries, and downstream people
generally can not. Look at my merges, and see how they say things like

Merge git://

* git:// (21 commits)
[CIFS] Remove debug statement
Fix possible access to undefined memory region.
[CIFS] Enable DFS support for Windows query path info
[CIFS] Enable DFS support for Unix query path info
[CIFS] add missing seq_printf to cifs_show_options for hard mount option

iow, when upstream does a merge, it's simply different from when
downstream does one - thanks exactly to having a specific purpose.

- I hopefully only merge "release points".

I don't pull from people at random points. I don't pull daily, or even
weekly. I pull when a sub-maintainer asks me to pull, and I've tried to
teach people to think of their pull requests as literally being
"releases" of their tree. Because they effectively are!

No, releases aren't perfect, and there will be bugs, but the same way
that I argued that maintainers should generally aim to pull from me
mainly at stable release points, I myself want to pull from downstream
only when there is _some_ reason to believe that it's a stable point.

So this isn't really a "broken symmetry", but it looks different
because subsystem "releases" are smaller and happen more often than a
"whole kernel release".

- My tree isn't so much a "development tree" as it is a "integration

IOW, the biggest reason for my tree to exist in the first place is
exactly the fact that it gives people a place to go to see what the
"union" of the development is. In contrast, the reason people would go
to the ALSA tree, or the networking tree, or any of the other specific
trees is exactly because they don't want the union, but want to see
what's recent in that particular area.

If somebody fetches the tip of the ALSA tree, they may expect
sound-related stuff to break, but you'd generally want to make sure
that the rest is as stable as possible (while not being _entirely_
stale, of course!)

If somebody fetches my tree, they want it all, and they *expect* to see
any breakage (and any new features) that everybody else could have

So the above hopefully explains why I do 350+ merges per release, but
still have the gall to tell other people that they shouldn't merge too

[ The corrollary to this all is that when downstream does a merge, think
about what the merge message can say. How would you descibe the merge?

Can you give a good description of what you merged, and why? That's one
thing that merging with releases can give you: you can say "merge with
release 'xyz'", and people actually understand the *meaning* of it. Your
merge message makes sense - and that implies that the merge itself
likely made sense.

If you cannot explain what and why you merged, you probably shouldn't be
merging - that's a good rule of thumb right there! Maybe that rule in
itself should already be seen as sufficient ]

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at