Document the configuration file

diff --git a/Documentation/howto/using-topic-branches.txt b/Documentation/howto/using-topic-branches.txt
index 6fc69e12ebf9b69eca369bee066858a3bf309f65..2c98194cb84d34bbcb5f3c0bc989728e46f7f9d3 100644 (file)
--- a/Documentation/howto/using-topic-branches.txt
+++ b/Documentation/howto/using-topic-branches.txt
@@ -1,13 +1,15 @@
 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.
 
 -Tony
 
-Last updated w.r.t. GIT 0.99.5
+Last updated w.r.t. GIT 1.1
 
 Linux subsystem maintenance using GIT
 -------------------------------------
@@ -29,7 +31,7 @@ test tree and then pull to the release tree as that would leave trivial
 patches blocked in the test tree waiting for complex changes to accumulate
 enough test time to graduate.
 
-Back in the BitKeeper days I achieved this my creating small forests of
+Back in the BitKeeper days I achieved this by creating small forests of
 temporary trees, one tree for each logical grouping of patches, and then
 pulling changes from these trees first to the test tree, and then to the
 release tree.  At first I replicated this in GIT, but then I realised
@@ -40,7 +42,7 @@ So here is the step-by-step guide how this all works for me.
 
 First create your work tree by cloning Linus's public tree:
 
- $ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git work
+ $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git work
 
 Change directory into the cloned tree you just created
 
@@ -50,7 +52,7 @@ 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
+ URL: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Pull: master:linus
  ^D
 
@@ -87,8 +89,16 @@ 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
+
+Important note!  If you have any local changes in these branches, then
+this merge will create a commit object in the history (with no local
+changes git will simply do a "Fast forward" merge).  Many people dislike
+the "noise" that this creates in the Linux history, so you should avoid
+doing this capriciously in the "release" branch, as these noisy commits
+will become part of the permanent history when you ask Linus to pull
+from the release branch.
 
 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
@@ -126,7 +136,7 @@ commit to this branch.
 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.
@@ -136,7 +146,7 @@ same branch into the "release" tree ready to go upstream.  This is where you
 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
@@ -164,7 +174,7 @@ output from:
 
 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
@@ -188,7 +198,7 @@ Here are some of the scripts that I use to simplify all this even further.
 
 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/refs/heads/linus)
@@ -229,7 +239,7 @@ test|release)
                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
@@ -243,7 +253,7 @@ gb=$(tput setab 2)
 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
@@ -260,7 +270,7 @@ do
        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