Added git-rebase sections

Minor edits

Makefile

@@ -10,7 +10,7 @@ book.xml: $(TXTFILES)
 book: book.xml book.css preface.html book/default.css
 	xmlto -m custom-html.xsl -o book html book.xml
 	sed -i 's/xmlns:fo[^ ]*//' book/*.html
-	-ls book/*.html | xargs -n 1 tidy -utf8 -m -i -q
+	ls book/*.html | xargs -n 1 tidy -utf8 -m -i -q
 	./makeover
 
 book/default.css: book.css
@@ -19,7 +19,7 @@ book/default.css: book.css
 
 book.html: book.xml
 	xmlto -m custom-nochunks.xsl html-nochunks $^
-	-tidy -utf8 -imq $@
+	tidy -utf8 -imq $@
 
 book.pdf: book.xml
 	docbook2pdf book.xml

grandmaster.txt

@@ -29,7 +29,7 @@ and in the "proj.git" directory, run
 
 From your computer, you can push via ssh:
 
- $ git push web.server:/path/to/proj.git HEAD
+ $ git push web.server:/path/to/proj.git master
 
 and people can get your project via
 
@@ -61,6 +61,44 @@ Did you just commit, but wish you had typed a different message? Realized you fo
 
 can help you out.
 
+Since this changes the history, only do this if you have yet to push your changes, otherwise your tree will diverge from other trees. Of course, if you control all the other trees too, then there is no problem since you can always overwrite them.
+
+== ... And Then Some ==
+
+Let's suppose the previous problem is ten times worse. After a lengthy session you've made a bunch of commits. But you're not quite happy with the way they're organized, and some of those commit messages could use some rewording. This is quite likely if you've been saving early and saving often. Then type
+
+ $ git rebase -i HEAD~10
+
+and the last 10 commits will appear in your favourite $EDITOR. A sample excerpt:
+
+    pick 5c6eb73 Added repo.or.cz link
+    pick a311a64 Reordered analogies in "Work How You Want"
+    pick 100834f Added push target to Makefile
+
+Then:
+
+- Remove commits by deleting lines.
+- Reorder commits by reordering lines.
+- Replace "pick" with "edit" to mark a commit for amending.
+- Replace "pick" with "squash" to merge a commit with the previous one.
+
+Next run *git-commit --amend* if you marked a commit for editing. Otherwise, run:
+
+ $ git-rebase --continue
+
+Again, you can only do this if no one else has your tree.
+
+== Local Changes Last ==
+
+You're working on an active project. You make some local commits over time, and
+then you sync with the official tree with a merge. This cycle repeats itself a few times before you're ready to push to the cetnral tree.
+
+But now the history in your local Git clone is a messy jumble of your changes and the official changes. You'd prefer to see all your changes in one contiguous section, and after all the official changes.
+
+This is a job for *git-rebase* as described above.
+
+Also see the manpage for other amazing uses of this command, which really deserves a chapter of its own. You can split commits. You can even rearrange branches of a tree!
+
 == Don't Lose Your HEAD ==
 
 The HEAD tag is like a cursor that normally points at the latest commit, advancing with each new commit. Some Git commands let you move it. For example:

intro.txt

@@ -12,7 +12,7 @@ But this will overwrite the old version. It's like those old school games which
 
 == Version Control ==
 
-When editing, you can "Save As..." a different file, or copy the file somewhere first before saving if you want to savour old versions. Maybe compress them too to save space. This is version control, but very primitive and labour-intensive. Computer games improved on this long ago, many of them allowing multiple automatically timestamped save slots.
+When editing, you can "Save As..." a different file, or copy the file somewhere first before saving if you want to savour old versions. Maybe compress them too to save space. This is version control, but very primitive and labour-intensive. Computer games improved on this long ago, many of them providing multiple automatically timestamped save slots.
 
 Let's make the problem slightly tougher now. Say you have a bunch of files that go together, such as collection of source code for the same project, or files for a website. Now if you want to keep an old version you have to archive a whole directory of stuff. Keeping many versions around is inconvenient to do by hand, and gets expensive fast.
 

secrets.txt

@@ -6,7 +6,7 @@ We take a peek under the hood and explain how Git performs its miracles. I will
 
 How can Git be so unobtrusive? Aside from occasional commits and merges, you can work as if you weren't aware that version control exists. That is, until you need it, and that's when you're glad Git was watching over you the whole time.
 
-Other version control systems don't let you forget about them. Permissions of files may be read-only unless you explicity tell the server which files you intend to edit. The central server might be keeping track of who's checked out which code, and when. When the network goes down, you'll soon suffer. Developers constantly struggle with virtual red tape and bureaucracy.
+Other version control systems don't let you forget about them. Permissions of files may be read-only unless you explicitly tell the server which files you intend to edit. The central server might be keeping track of who's checked out which code, and when. When the network goes down, you'll soon suffer. Developers constantly struggle with virtual red tape and bureaucracy.
 
 The secret is the ".git" directory in your working directory. Git keeps the history of your project here. The initial "." stops it showing up in *ls* listings. Except when you're pushing and pulling changes, all version control operations operate within this directory.
 
@@ -41,6 +41,8 @@ Git heuristically ferrets out renames and copies between successive versions. In
 You may have been wondering what format those online Git repositories use.
 They're plain Git repositories, just like your ".git" directory except they've got names like "proj.git", and they have no working directory associated with them.
 
+Most Git commands expect the Git index to live in ".git", and will fail on these bare repositories. Fix this by setting the "GIT_DIR" environment variable to the path of the bare repository.
+
 == Git Shortcomings ==
 
 There are some Git issues I've swept under the carpet until now. Some can be handled easily with scripts, others require reorganizing or redefining the project, and as for Windows annoyances, one will just have to wait. Or better yet, pitch in and help!
@@ -53,7 +55,7 @@ Git on Window can be cumbersome. It works with Cygwin installed, though is slowe
 
 If your project is very large and contains many unrelated files that are constantly being changed, Git may be disadvantaged more than other systems because single files are not tracked. Git tracks changes to the whole project, which is usually beneficial.
 
-A solution is to break up your project into pieces, each consisting of files that are related.
+A solution is to break up your project into pieces, each consisting of related files. The *git-submodule* command can help if you still the group the pieces together.
 
 === Volatile Projects ===