Message-ID: <alpine.LFD.1.10.0805211043590.3081@woody.linux-foundation.org>
Date:	Wed, 21 May 2008 11:11:40 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Takashi Iwai <tiwai@...e.de>
cc:	Rene Herman <rene.herman@...access.nl>,
	alsa-devel@...a-project.org,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [alsa-devel] HG -> GIT migration



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

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.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6
    
      * git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6: (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 
   tree".

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

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

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

				Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists