Converted to AsciiDoc

Makefile

@@ -1,13 +1,13 @@
 .PHONY: target clean sync push
 
-target: book
+target: book book/default.css
 
-TXTFILES=intro.txt basic.txt clone.txt branch.txt grandmaster.txt secrets.txt
+TXTFILES=preface.txt intro.txt basic.txt clone.txt branch.txt grandmaster.txt secrets.txt
 
 book.xml: $(TXTFILES)
-	cat $^ | sed 's/\*\([^ *][^*]*[^ *]\)\*/<command>\1<\/command>/g' | ./bookmake > book.xml
+	( for FILE in $^ ; do cat $$FILE ; echo ; done ) | asciidoc -d book -b docbook - > $@
 
-book: book.xml book.css preface.html book/default.css
+book: book.xml
 	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

basic.txt

@@ -1,8 +1,8 @@
-= Basic Tricks =
+== Basic Tricks ==
 
 Rather than diving into a sea of Git commands, use these elementary examples to get your feet wet. Despite their simplicity, each of them are useful in real life.
 
-== Saving State ==
+=== Saving State ===
 
 When I'm about to attempt something drastic I like to save the current state, so I can go back and try again should things go awry.
 
@@ -24,7 +24,7 @@ to go back to where you were. To save the state again:
 
 Tip: the hyphen after "git" may be replaced by a space if you prefer.
 
-=== Add, Delete, Rename ===
+==== Add, Delete, Rename ====
 
 The above will only keep track of the files that were present when you first ran *git-add*. If you add new files or subdirectories, you'll have to tell Git:
 
@@ -38,7 +38,7 @@ Renaming a file is the same as removing the old name and adding the new name. Th
 
  $ git-mv OLDFILE NEWFILE
 
-== Advanced Undo/Redo ==
+=== Advanced Undo/Redo ===
 
 Running:
 
@@ -78,7 +78,7 @@ To take the computer game analogy again:
 
 For reset and checkout, you can choose only to restore particular files and subdirectories by appending them after the command.
 
-== Dowloading Files ==
+=== Dowloading Files ===
 
 If a project uses Git to manage its files, you can get a copy with:
 
@@ -90,13 +90,13 @@ For example, to get all the files I used to create this site:
 
 We'll have a lot more to say about the *clone* command later.
 
-== The Bleeding Edge ==
+=== The Bleeding Edge ===
 
 If a project uses Git to manage its files, and you've already downloaded a copy using *git-clone*, you can upgrade to the latest version with:
 
  $ git-pull
 
-== Instant Publishing ==
+=== Instant Publishing ===
 
 Let's say you've written a script you'd like to share with others. You could just tell them to download from your computer, but if they do so while you're improving the script or making experimental changes, they could wind up in trouble.  Of course, this is why release cycles exist. Code is written, and at certain points in time, when it's suitable for others, it gets released.
 
@@ -124,7 +124,7 @@ and your users can upgrade their version by changing to the directory containing
 
 Your users will never end up with a version of your script you don't want them to see. Obviously this trick works for anything, not just scripts.
 
-== What Have I Done? ==
+=== What Have I Done? ===
 
 Find out what changes you've made since the last commit with:
 

book.css

@@ -8,6 +8,10 @@ tt, code, pre, .type {
     font-size: 90%;
 }
 
+ul li p {
+    margin-bottom:0;
+}
+
 /* Based on http://phrogz.net/CSS/columns3.html */
 div.toc {
     float: left;

branch.txt

@@ -1,4 +1,4 @@
-= Branch Wizardry =
+== Branch Wizardry ==
 
 Instant branching and merging are the most lethal of Git's killer features.
 
@@ -12,7 +12,7 @@ But cloning still entails copying the whole working directory as well as the ent
 
 With this magic word, the files in your directory suddenly shapeshift from one version to another. This transformation can do more than merely go back or forward in history. Your files can morph from the last release to the experimental version to the current development version to your friend's version and so on.
 
-== The Boss Key ==
+=== The Boss Key ===
 
 Ever play one of those games where at the push of a button ("the boss key"), the screen would instantly display a spreadsheet or something? So if the boss walked in the office while you were playing the game you could quickly hide this fact?
 
@@ -39,7 +39,7 @@ and hey presto! The text file is restored. And if the boss decides to snoop arou
 
 You can switch between the two versions of the file as much as you like, and commit to each independently.
 
-== Dirty Work ==
+=== Dirty Work ===
 
 Say you're working on some feature, and for some reason, you need to go back to an old version and temporarily need to put in a few prints statements to see how something works. Then:
 
@@ -64,7 +64,7 @@ We touched upon this command in an earlier chapter, when discussing loading old
 
 Hence after checking out an old state, Git automatically puts you in a new, unnamed branch, which can be named and saved with *git-checkout -b*.
 
-== Quick Fixes ==
+=== Quick Fixes ===
 
 You're in the middle of something when you are told to drop everything and fix a newly discovered bug:
 
@@ -79,7 +79,7 @@ Then once you've fixed the bug:
 
 ...and resume work on your original task.
 
-== Uninterrupted Workflow ==
+=== Uninterrupted Workflow ===
 
 Some projects require your code to be reviewed before you may submit it. To make life easier for those reviewing your code, if you have a big change to make you might break it into two or more parts, and get each part separately reviewed.
 
@@ -114,7 +114,7 @@ and again, the second part is ready to be reviewed.
 
 It's easy to extend this trick for any number of parts.
 
-== Managing Branches ==
+=== Managing Branches ===
 
 Type:
 
@@ -124,17 +124,17 @@ to list all the branches. There is always a branch named "master", and you start
 
 The branch command can also do other operations with branches. See *git help branch* for details.
 
-== Work How You Want ==
+=== Work How You Want ===
 
-Applications like [[http://www.mozilla.com/][Mozilla Firefox]] allow you to open multitple tabs and multiple windows. Swtiching tabs gives you different content in the same window. Git branching is like tabs for your working directory. Continuing this analogy, Git cloning is like opening a new window. Being able to do both easily makes for a better user experience.
+Applications like http://www.mozilla.com/[Mozilla Firefox] allow you to open multitple tabs and multiple windows. Swtiching tabs gives you different content in the same window. Git branching is like tabs for your working directory. Continuing this analogy, Git cloning is like opening a new window. Being able to do both easily makes for a better user experience.
 
 On a higher level, several Linux window managers allow you to have multiple desktops, which means you can instantly view a different state of the desktop. This is similar to branching in Git, whereas Git cloning would be like attaching another monitor where you can open more windows.
 
-Yet another example is the [[http://www.gnu.org/software/screen/][*screen*]] utility. This gem allows you to create, destroy and switch between multiple terminal sessions in the same terminal. Instead of opening new terminals (clone), you can use the same one if you run *screen* (branch). In fact, you can do a lot more with *screen* but that's a topic for another day.
+Yet another example is the http://www.gnu.org/software/screen/[*screen*] utility. This gem allows you to create, destroy and switch between multiple terminal sessions in the same terminal. Instead of opening new terminals (clone), you can use the same one if you run *screen* (branch). In fact, you can do a lot more with *screen* but that's a topic for another day.
 
 Cloning, branching and merging are fast and local in Git, encouraging you to use the combination that best suits you. Git allows you to work exactly how you want.
 
-=== Personal Experience ===
+==== Personal Experience ====
 
 The equivalent of branching and cloning in centralized version control systems, when it exists, requires network communication. This automatically precludes working offline. Secondly, these systems need more expensive network infrastructure, especially as the number of users grows.
 

clone.txt

@@ -1,10 +1,10 @@
-= Cloning Around =
+== Cloning Around ==
 
 In older version control systems, the standard way to get a saved state was checkout. You'd checkout a bunch of files in the requested saved state.
 
 In Git and other distributed version control systems, cloning is the standard operation. To get files you create a clone of the entire repository. In other words, you practically create a mirror of the central server. So anything the main repository can do, you can do.
 
-== Sync Computers ==
+=== Sync Computers ===
 
 This is the reason I first used Git. I can tolerate making tarballs or using *rsync* for backups and basic syncing. The problem was sometimes I'd edit on my laptop, other times on my desktop, and they may not have talked to each other in between.
 
@@ -29,7 +29,7 @@ to push the current state to the other computer. Next time you're logged in to t
 
 to update the files before working on them. Be aware that you'll lose any uncommitted changes when you do this.
 
-== Classic Source Control ==
+=== Classic Source Control ===
 
 Initialize a Git repository for your files: 
 
@@ -40,10 +40,10 @@ Initialize a Git repository for your files:
 On the central server, initialize an empty Git repository with some name,
 and start the Git daemon if necessary:
 
- $ GIT_DIR=proj.git git-init-db
+ $ GIT_DIR==proj.git git-init-db
  $ git-daemon --detach  # it might already be running
 
-Some public hosts, such as [[http://repo.or.cz][repo.or.cz]], will have a different method for setting up the initially empty Git repository, such as filling in a form on a webpage.
+Some public hosts, such as http://repo.or.cz[repo.or.cz], will have a different method for setting up the initially empty Git repository, such as filling in a form on a webpage.
 
 Push your project to the central server with:
 
@@ -63,7 +63,7 @@ If the main server has been updated, the latest version needs to be checked out
  $ git commit -a
  $ git pull
 
-== Forking a Project ==
+=== Forking a Project ===
 
 Sick of the way a project is being run? Think you could do a better job? Then on your server:
 
@@ -75,15 +75,15 @@ At any later time, you can merge in the changes from the original project with:
 
  $ git pull
 
-== Ultimate Backups ==
+=== Ultimate Backups ===
 
 Want numerous tamper-proof geographically diverse redundant archives? If your project has many developers, don't do anything! Every clone of your code is effectively a backup. Not just of the current state of the project, but of your project's entire history. Thanks to cryptographic hashing, if anyone's clone becomes corrupted, it will be spotted as soon as they try to communicate with others.
 
 If your project is not so popular, find as many servers as you can to host clones.
 
 The truly paranoid should always write down the latest 20-byte SHA1 hash of the HEAD somewhere safe. It has to be safe, not private. For example, publishing it in a newspaper would work well, because it's hard for an attacker to alter every copy of a newspaper.
 
-== Light-Speed Multitask ==
+=== Light-Speed Multitask ===
 
 Say you want to work on several features in parallel. Then after committing your project:
 
@@ -97,7 +97,7 @@ At any time, you can commit and pull changes from the other clone.
 
  $ git-pull /the/other/clone
 
-== Guerilla Version Control ==
+=== Guerilla Version Control ===
 
 Are you working on a project that uses some other version control system, and you sorely miss Git? Then initialize a Git repository in your working directory:
 

grandmaster.txt

@@ -1,26 +1,26 @@
-= Git Grandmastery =
+== Git Grandmastery ==
 
 This pretentiously named page is my dumping ground for uncategorized Git tricks.
 
-== Source Releases ==
+=== Source Releases ===
 
 For my projects, Git tracks exactly the files I'd like to archive and release to users. So to create a tarball of the source code, I run:
 
- $ git-archive --format=tar --prefix=proj-1.2.3/ HEAD
+ $ git-archive --format==tar --prefix==proj-1.2.3/ HEAD
 
-== Changelog Generation ==
+=== Changelog Generation ===
 
-It's good practice to keep a [[http://en.wikipedia.org/wiki/Changelog][changelog]], and some projects even require it. If you've been committing frequently, which you should, generate a Changelog by typing
+It's good practice to keep a http://en.wikipedia.org/wiki/Changelog[changelog], and some projects even require it. If you've been committing frequently, which you should, generate a Changelog by typing
 
  $ git-log > ChangeLog
 
-== Git Over SSH, HTTP ==
+=== Git Over SSH, HTTP ===
 
 Suppose you have ssh access to your web server, and it does not have Git installed, which is not an uncommon situation. Then download, compile and install Git in your account.
 
 Create a repository in your web directory:
 
- $ GIT_DIR=proj.git git-init
+ $ GIT_DIR==proj.git git-init
 
 and in the "proj.git" directory, run
 
@@ -35,7 +35,7 @@ and people can get your project via
 
  $ git clone http://web.server/proj.git
 
-== Commit What Changed ==
+=== Commit What Changed ===
 
 Telling Git when you've added, deleted and renamed files gets tedious. Instead, try:
 
@@ -53,7 +53,7 @@ If you have a big list of directories and files that should never be version con
 
 You can also exclude files on a per-directory basis. See the help page.
 
-== I Stand Corrected ==
+=== I Stand Corrected ===
 
 Did you just commit, but wish you had typed a different message? Realized you forgot to add a file? Then:
 
@@ -63,7 +63,7 @@ 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 ==
+=== ... 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
 
@@ -88,7 +88,7 @@ Next run *git-commit --amend* if you marked a commit for editing. Otherwise, run
 
 Again, you can only do this if no one else has your tree.
 
-== Local Changes Last ==
+=== 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.
@@ -99,7 +99,7 @@ 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 ==
+=== 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:
 
@@ -117,8 +117,8 @@ But suppose you never took it down? Don't worry, for commands like these, Git sa
 
  $ git reset ORIG_HEAD
 
-== Building On Git ==
+=== Building On Git ===
 
 In true UNIX fashion, Git's design allows it to be easily used as a low-level component of other programs. There are GUI interfaces, web interfaces, alternative command-line interfaces, and perhaps soon you will have a script or two of your own that calls Git.
 
-See [[http://git.or.cz/][the Git homepage]] for some examples.
+See http://git.or.cz/[the Git homepage] for some examples.