git branches strategy (was Re: merge status)

[Jeff Garzik <jgarzik@pobox.com>]

Andrew Morton wrote:
> Most of the other git-tree maintainers don't bother with any of that. 
> acpi, agp, alsa, arm, ...  xfs.  The trees which have special -mm branches
> are just drm, ieee1394, jfs, mips and netdev.

[related tangent, in case this is useful to others]

It's not quite correct to say that I have a special -mm branch.  In my 
two primary work areas, libata-dev.git and netdev-2.6.git, I have a 
bunch of branches, which fall into three categories:

	'master':	vanilla upstream Linus tree
	themes:		various patch queues, each for a single purpose.

			standard patch queues include...

			upstream: stuff queued for upstream
			upstream-fixes: stuff queued for -rc

			8139-thread: example non-upstream dev branch
			ncq: another non-upstream dev branch

	'ALL':		a superset merge of all theme branches which
			are considered OK for testing by brave users.

The 'ALL' superset branch is not only what you (Andrew) pull into -mm, 
its also the basis for -libataN and -netdevN patches, and in general the 
best way for users to slurp "all the useful bits."

Using theme branches and a superset branch allows for maximum parallel 
development -- even applying conflicting patches -- and then using git 
to merge them together.  The separated-out branches also allow for 
fine-grained selection of the material to push upstream, i.e. no false 
dependencies, easier cherrypicking.

I've actually worked this way since the early BitKeeper days; BK didn't 
make it easy for me to export the tons of local theme branches I 
manipulated, just the superset branch.  Since git makes it easy, you 
finally get the full picture of libata/netdev development, and the best 
of both worlds:  both a superset branch (easy testing) and theme 
branches (parallel development).

	Jeff