Dave Airlie wrote:

quoted

When I merge a patch for drivers/net/forcedeth.c, I merge it into a
brand new 'forcedeth' repository, a peer to the 40+ other such
repository.  Under BitKeeper, I made these repositories available merged
together into one big "netdev-2.6" repository because it was too time
consuming to make the individual 50+ trees publicly available.  With
git, developers have direct access to the individual trees.

I thought I would write up a quick guide describing how to mess around
with the netdev and libata-dev trees, and with git in general.

Thanks for this, I'm starting to get up to speed on git now...

Two questions,

1. when you want to publish your tree what do you do? just rsync it
onto kernel.org?

Basically.  I copy the attached script into each repo, customize the 
script for the upload destination.

When I publish the tree, I just cd to the toplevel dir on my local 
workstation, and run "./push"

2. When you are taking things from your queue for Linus do you create
another tree and merge your branches into it or what?

Not quite sure what you're asking, but I'll attempt to answer anyway :)

When I prepare a submission for Linus, I will pull several branches into 
a single 'for-linus' conglomeration branch.  I do this with the 
following incantation, for each branch I am pushing upstream:

git-resolve-script $(cat .git/HEAD) $(cat .git/refs/heads/$branch) \
	`pwd` $branch

(Note that I modified my git-resolve-script to take an additional $4 
argument, which causes the string " branch $4" to be added to the merge 
cset's commit msg)

After I take care of all the merge conflicts[1] from the 
git-resolve-script run, I give the big pile of mush a final build and 
test, and then run "./push".

For the "please pull" email, I use diffstat, git-diff-tree, 
git-changes-script and the newly written git-shortlog.

	Jeff



[1] I'm still scared of conflicts in the merge process.  Simple and 
automatic merging works just fine, like it did under BitKeeper.  But if 
there are conflicts that cause git-pull-script/git-resolve-script to 
bail, then I bail as well:  I export a patch, run patch(1), and then 
handle the merge the Old Fashioned Way(tm) by looking at .rej files.

I really wish somebody would write a merge helper for git that places 
the conflicts side-by-side in the code [in the working dir].  BitKeeper 
and CVS both presented conflicts to you in this manner.

The "I resolved this conflict, now let's continue where we left off" 
process is still quite raw in git.  I suppose this is something that is 
left for others to script, above the plumbing, but hey...