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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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]
  Powered by Linux