Messages in this thread | | | Date | Sat, 04 Jun 2005 06:26:09 -0400 | From | Jeff Garzik <> | Subject | 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
| |