Date: Mon, 15 Aug 2005 12:17:41 -0700
From: tony.luck@intel.com
Subject: Some tutorial text (was git/cogito workshop/bof at linuxconf au?)
+Abstract: In this article, Tony Luck discusses how he uses GIT
+ as a Linux subsystem maintainer.
Here's something that I've been putting together on how I'm using
GIT as a Linux subsystem maintainer.
-I suspect that I'm a bit slap-happy with the "git checkout" commands in
-the examples below, and perhaps missing some of the _true-git_ ways of
-doing things.
-
-Tony
+Last updated w.r.t. GIT 0.99.9f
+
Linux subsystem maintenance using GIT
-------------------------------------
$ cd work
-Make a GIT branch named "linus", and rename the "origin" branch as linus too:
+Set up a remotes file so that you can fetch the latest from Linus' master
+branch into a local branch named "linus":
+
+ $ cat > .git/remotes/linus
+ URL: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ Pull: master:linus
+ ^D
- $ git checkout -b linus
- $ mv .git/branches/origin .git/branches/linus
+and create the linus branch:
+
+ $ git branch linus
The "linus" branch will be used to track the upstream kernel. To update it,
you simply run:
- $ git checkout linus && git pull linus
+ $ git fetch linus
+
+you can do this frequently (and it should be safe to do so with pending
+work in your tree, but perhaps not if you are in mid-merge).
-you can do this frequently (as long as you don't have any uncommited work
-in your tree).
+If you need to keep track of other public trees, you can add remote branches
+for them too:
-If you need to keep track of other public trees, you can add branches for
-them too:
+ $ git branch another
+ $ cat > .git/remotes/another
+ URL: ... insert URL here ...
+ Pull: name-of-branch-in-this-remote-tree:another
+ ^D
- $ git checkout -b another linus
- $ echo URL-for-another-public-tree > .git/branches/another
+and run:
+
+ $ git fetch another
Now create the branches in which you are going to work, these start
out at the current tip of the linus branch.
These can be easily kept up to date by merging from the "linus" branch:
- $ git checkout test && git resolve test linus "Auto-update from upstream"
- $ git checkout release && git resolve release linus "Auto-update from upstream"
+ $ git checkout test && git merge "Auto-update from upstream" test linus
+ $ git checkout release && git merge "Auto-update from upstream" release linus
-Set up so that you can push upstream to your public tree:
+Set up so that you can push upstream to your public tree (you need to
+log-in to the remote system and create an empty tree there before the
+first push).
- $ echo master.kernel.org:/ftp/pub/scm/linux/kernel/git/aegl/linux-2.6.git > .git/branches/origin
+ $ cat > .git/remotes/mytree
+ URL: master.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
+ Push: release
+ Push: test
+ ^D
-and then push each of the test and release branches using:
+and the push both the test and release trees using:
- $ git push origin test
-and
- $ git push origin release
+ $ git push mytree
+
+or push just one of the test and release branches using:
+
+ $ git push mytree test
+or
+ $ git push mytree release
Now to apply some patches from the community. Think of a short
snappy name for a branch to hold this patch (or related group of
When you are happy with the state of this change, you can pull it into the
"test" branch in preparation to make it public:
- $ git checkout test && git resolve test speed-up-spinlocks "Pull speed-up-spinlock changes"
+ $ git checkout test && git merge "Pull speed-up-spinlock changes" test speed-up-spinlocks
It is unlikely that you would have any conflicts here ... but you might if you
spent a while on this step and had also pulled new versions from upstream.
see the value of keeping each patch (or patch series) in its own branch. It
means that the patches can be moved into the "release" tree in any order.
- $ git checkout release && git resolve release speed-up-spinlocks "Pull speed-up-spinlock changes"
+ $ git checkout release && git merge "Pull speed-up-spinlock changes" release speed-up-spinlocks
After a while, you will have a number of branches, and despite the
well chosen names you picked for each of them, you may forget what
is empty. At this point the branch can be deleted:
- $ rm .git/refs/heads/branchname
+ $ git branch -d branchname
Some changes are so trivial that it is not necessary to create a separate
branch and then merge into each of the test and release branches. For
case "$1" in
test|release)
- git checkout $1 && git resolve $1 linus "Auto-update from upstream"
+ git checkout $1 && git merge "Auto-update from upstream" $1 linus
;;
linus)
- before=$(cat .git/HEAD)
- git checkout linus && git pull linus
- after=$(cat .git/HEAD)
+ before=$(cat .git/refs/heads/linus)
+ git fetch linus
+ after=$(cat .git/refs/heads/linus)
if [ $before != $after ]
then
git-whatchanged $after ^$before | git-shortlog
echo $1 already merged into $2 1>&2
exit 1
fi
- git checkout $2 && git resolve $2 $1 "Pull $1 into $2 branch"
+ git checkout $2 && git merge "Pull $1 into $2 branch" $2 $1
;;
*)
usage
rb=$(tput setab 1)
restore=$(tput setab 9)
-if [ `git-rev-tree release ^test | wc -c` -gt 0 ]
+if [ `git-rev-list release ^test | wc -c` -gt 0 ]
then
echo $rb Warning: commits in release that are not in test $restore
git-whatchanged release ^test
status=
for ref in test release linus
do
- if [ `git-rev-tree $branch ^$ref | wc -c` -gt 0 ]
+ if [ `git-rev-list $branch ^$ref | wc -c` -gt 0 ]
then
status=$status${ref:0:1}
fi
projects / git.git / blobdiff