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
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]