Re: [doc][git] playing with git, and netdev/libata-dev trees

Dave Airlie wrote:
>>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...


#!/bin/sh

rsync -e ssh --verbose --delete --stats --progress -az .git/ master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html