en/* updated to translation state

Makefile

@@ -16,12 +16,15 @@ book.xml: $(addprefix $(LANG)/,$(TXTFILES))
 	# Concatenate the text files and feed to AsciiDoc.
 	# If a file has not yet been translated for the target language,
 	# then substitute the English version.
-	# Kludge to make preface sections work for languages besides English
-	# for older AsciiDoc versions.
-	CONF=lang-$(LANG).conf; [ -f $$CONF ] || CONF=lang-en.conf; \
+	# Kludge to support any translation of "Preface".
+	echo '[specialsections]' > conf ; \
+	if [ $(LANG) != ru ]; then \
+	sed -n '/^== .* ==$$/p' $(LANG)/preface.txt | sed 's/^== \(.*\) ==$$/^\1$$=preface/' >> conf ; \
+	else \
+	cp lang-ru.conf conf ; fi ; \
 	( for FILE in $^ ; do if [ -f $$FILE ]; then cat $$FILE; else \
 	cat en/$$(basename $$FILE); fi; echo ; done ) | \
-	asciidoc -a lang=$(LANG) -d book -b docbook -f $$CONF - > $@
+	asciidoc -a lang=$(LANG) -d book -b docbook -f conf - > $@
 
 # This rule allows unfinished translations to build.
 # Report an error if the English version of the text file is missing.

en/branch.txt

@@ -59,7 +59,7 @@ What if you wanted to save the temporary changes after all? Easy:
 
  $ git checkout -b dirty
 
-and commit before switching back to the master branch. Whenever you want to return to the dirty changes, simply type
+and commit before switching back to the master branch. Whenever you want to return to the dirty changes, simply type:
 
  $ git checkout dirty
 
@@ -77,38 +77,34 @@ You're in the middle of something when you are told to drop everything and fix a
 Then once you've fixed the bug:
 
  $ git commit -a -m "Bug fixed"
- $ git push  # to the central repository
  $ git checkout master
 
-and resume work on your original task.
-
-You can even 'merge' in the bugfix you just made, either by typing:
+and resume work on your original task. You can even 'merge' in the freshly
+baked bugfix:
 
  $ git merge fixes
 
-or:
-
- $ git pull
-
-since you have already pushed the bugfix to the main repository.
-
 === Merging ===
 
 With some version control systems, creating branches is easy but merging them
 back together is tough. With Git, merging is so trivial that you might be
 unaware of it happening.
 
-Indeed, though we have just introduced *git merge*, we encountered merging long ago. The *pull* command in fact fetches commits and then merges them into your current branch. If you have no local changes, then the merge is a 'fast forward', a degenerate case akin to fetching the latest version in a centralized version control system. But if you do have local changes, Git will automatically merge, and report any conflicts.
+We actually encountered merging long ago. The *pull* command in fact 'fetches'
+commits and then merges them into your current branch. If you have no local
+changes, then the merge is a 'fast forward', a degenerate case akin to fetching
+the latest version in a centralized version control system. But if you do have
+local changes, Git will automatically merge, and report any conflicts.
 
 Ordinarily, a commit has exactly one 'parent commit', namely, the previous
 commit. Merging branches together produces a commit with at least two parents.
 This begs the question: what commit does `HEAD~10` really refer to? A commit
 could have multiple parents, so which one do we follow?
 
 It turns out this notation chooses the first parent every time. This is
-desirable because commits in the current branch become the first parents during
-a merge; frequently you're only concerned with the changes you made in the
-current branch, as opposed to changes merged in from other branches.
+desirable because the current branch becomes the first parent during a merge;
+frequently you're only concerned with the changes you made in the current
+branch, as opposed to changes merged in from other branches.
 
 You can refer to a specific parent with a caret. For example, to show
 the logs from the second parent:
@@ -148,37 +144,40 @@ and often you'll want to go back and fix something in Part I.
 If you're lucky, or very good, you can skip these lines.
 
  $ git checkout master  # Go back to Part I.
- $ edit files           # Fix Part I.
+ $ fix_problem
+ $ git commit -a        # Commit the fixes.
  $ git checkout part2   # Go back to Part II.
  $ git merge master     # Merge in those fixes.
 
 Eventually, Part I is approved:
 
  $ git checkout master  # Go back to Part I.
- $ some_command         # Some command you're supposed to run when the
-                        # current working directory is officially ready.
+ $ submit files         # Release to the world!
  $ git merge part2      # Merge in Part II.
- $ git branch -d part2
+ $ git branch -d part2  # Delete "part2" branch.
 
 Now you're in the `master` branch again, with Part II in the working directory.
 
 It's easy to extend this trick for any number of parts. It's also easy to
 branch off retroactively: suppose you belatedly realize you should have created
 a branch 7 commits ago. Then type:
 
- $ git branch -m master part2
- $  # Rename "master" branch to "part2".
- $ git checkout HEAD~7 -b master
+ $ git branch -m master part2  # Rename "master" branch to "part2".
+ $ git branch master HEAD~7    # Create new "master", 7 commits upstream.
 
 The `master` branch now contains just Part I, and the `part2` branch contains
-the rest.
+the rest. We are in the latter branch; we created `master` without switching to
+it, because we want to continue work on `part2`. This is unusual. Until now,
+we've been switching to branches immediately after creation, as in:
+
+ $ git checkout HEAD~7 -b master  # Create a branch, and switch to it.
 
 === Reorganizing a Medley ===
 
 Perhaps you like to work on all aspects of a project in the same branch. You want to keep works-in-progress to yourself and want others to see your commits only when they have been neatly organized. Start a couple of branches:
 
-  $ git checkout -b sanitized
-  $ git checkout -b medley
+  $ git branch sanitized    # Create a branch for sanitized commits.
+  $ git checkout -b medley  # Create and switch to a branch to work in.
 
 Next, work on anything: fix bugs, add features, add temporary code, and so forth, committing often along the way. Then:
 
@@ -237,7 +236,7 @@ commands.
 Consider web browsers. Why support multiple tabs as well as multiple windows?
 Because allowing both accommodates a wide variety of styles. Some users like to
 keep only one browser window open, and use tabs for multiple webpages. Others
-might insist on the other extreme: multiple windows with no extra tabs anywhere.
+might insist on the other extreme: multiple windows with no tabs anywhere.
 Others still prefer something in between.
 
 Branching is like tabs for your working directory, and cloning is like opening

en/clone.txt

@@ -121,9 +121,12 @@ Say you want to work on several features in parallel. Then commit your project a
 
  $ git clone . /some/new/directory
 
-Git exploits hard links and file sharing as much as safely possible to create this clone, so it will be ready in a flash, and you can now work on two independent features simultaneously. For example, you can edit one clone while the other is compiling.
+Thanks to http://en.wikipedia.org/wiki/Hard_link[hardlinking], local clones
+require less time and space than a plain backup.
 
-At any time, you can commit and pull changes from the other clone.
+You can now work on two independent features simultaneously. For example, you
+can edit one clone while the other is compiling. At any time, you can commit
+and pull changes from the other clone:
 
  $ git pull /the/other/clone HEAD
 

en/grandmaster.txt

@@ -164,7 +164,7 @@ One popular resident is +workdir/git-new-workdir+. Via clever symlinking, this s
 
   $ git-new-workdir an/existing/repo new/directory
 
-The new directory and the files within can be thought of as a clone, except since the history is shared, the two trees automatically stay in sync. There's no need to merge, push or pull.
+The new directory and the files within can be thought of as a clone, except since the history is shared, the two trees automatically stay in sync. There's no need to merge, push, or pull.
 
 === Daring Stunts ===
 
@@ -205,23 +205,12 @@ Next time, that pesky command will work!
 
 === Preventing Bad Commits ===
 
-Stupid mistakes abound in the histories of many of my projects. The most
-frightening are missing files due to a forgotten *git add*. Luckily I
-have yet to lose crucial data though accidental omission because I rarely
-delete original working directories. I typically notice the error a few commits
-later, so the only damage is a bit of missing history and a sheepish admission
-of guilt.
-
-I also regularly commit (literally and git-erally) the lesser transgression of
-trailing whitespace. Though harmless, I wish these also never appeared on the
+Stupid mistakes pollute my repositories. Most frightening are missing files due
+to a forgotten *git add*. Lesser transgressions are trailing whitespace and
+unresolved merge conflicts: though harmless, I wish these never appeared on the
 public record.
 
-In addition, though unscathed so far, I worry about leaving merge conflicts
-unresolved. Usually I catch them when I build a project, but there are some
-cases this can overlook.
-
-If only I had bought idiot insurance by using a _hook_ to alert me about these
-problems:
+If only I had bought idiot insurance by using a _hook_ to alert me about these problems:
 
  $ cd .git/hooks
  $ cp pre-commit.sample pre-commit  # Older Git versions: chmod +x pre-commit
@@ -237,11 +226,7 @@ For this guide, I eventually added the following to the beginning of the
    exit 1
  fi
 
-Several git operations support hooks; see *git help hooks*. One can write hooks
-to complain about spelling mistakes in commit messages, add new files, indent
-paragraphs, append an entry to a webpage, play a sound, and so on.
-
-We activated the sample *post-update* hook earlier when discussing Git over
-HTTP; this causes Git to run this script whenever the head has moved. The
-sample post-update script updates a few files Git needs for communication over
-Git-agnostic transports such as HTTP.
+Several git operations support hooks; see *git help hooks*. We activated the
+sample *post-update* hook earlier when discussing Git over HTTP. This runs
+whenever the head moves. The sample post-update script updates files Git needs
+for communication over Git-agnostic transports such as HTTP.

en/history.txt

@@ -8,7 +8,7 @@ differs to yours, you will have trouble reconciling when your trees interact.
 
 Some developers strongly feel history should be immutable, warts and all.
 Others feel trees should be made presentable before they are unleashed in
-public. Git accommodates both viewpoints. Like cloning, branching and merging,
+public. Git accommodates both viewpoints. Like cloning, branching, and merging,
 rewriting history is simply another power Git gives you. It is up to you
 to use it wisely.
 

en/intro.txt

@@ -18,7 +18,7 @@ Let's make the problem slightly tougher. Say you have a bunch of files that go t
 
 With some computer games, a saved game really does consist of a directory full of files. These games hide this detail from the player and present a convenient interface to manage different versions of this directory.
 
-Version control systems are no different. They all have nice interfaces to manage a directory of stuff. You can save the state of the directory every so often, and you can load any one of the saved states later on. Unlike most computer games, they're usually smart about conserving space. Typically, only a few files change between version to version, and not by much. Storing the differences instead of entire new copies saves room.
+Version control systems are no different. They all have nice interfaces to manage a directory of stuff. You can save the state of the directory every so often, and you can load any one of the saved states later on. Unlike most computer games, they're usually smart about conserving space. Typically, only a few files change from version to version, and not by much. Storing the differences instead of entire new copies saves room.
 
 === Distributed Control ===
 

en/preface.txt

@@ -13,7 +13,10 @@ Rather than go into details, we provide rough instructions for particular effect
 .Translations
 
  - http://docs.google.com/View?id=dfwthj68_675gz3bw8kj[Chinese (Simplified)]: by JunJie, Meng and JiangWei.
- - link:/~blynn/gitmagic/intl/es/[Spanish]: by Rodrigo Toledo.
+ - link:/~blynn/gitmagic/intl/es/[Spanish]: by Rodrigo Toledo and Ariset Llerena Tapia.
+ - link:/~blynn/gitmagic/intl/de/[German]: by Benjamin Bellee and Armin Stebich. Armin also hosts http://gitmagic.lordofbikes.de/[the German translation on his website].
+ - link:/~blynn/gitmagic/intl/ru/[Russian]: by Tikhon Tarnavsky, Mikhail Dymskov, and others.
+ - link:/~blynn/gitmagic/intl/fr/[French]: by Alexandre Garel. Also hosted at http://tutoriels.itaapy.com/[itaapy].
  - http://www.slideshare.net/slide_user/magia-git[Portuguese]: by Leonardo Siqueira Rodrigues [http://www.slideshare.net/slide_user/magia-git-verso-odt[ODT version]].
 
 .Other Editions
@@ -25,16 +28,16 @@ Rather than go into details, we provide rough instructions for particular effect
 
 === Thanks! ===
 
-Dustin Sallings, Alberto Bertogli, James Cameron, Douglas Livingstone, Michael Budde, Richard Albury, Tarmigan, Derek Mahar, Frode Aannevik, Keith Rarick, Andy Somerville, Ralf Recker, Øyvind A. Holm, Miklos Vajna, Sébastien Hinderer, Thomas Miedema, and Joe Malin contributed corrections and improvements.
+Dustin Sallings, Alberto Bertogli, James Cameron, Douglas Livingstone, Michael Budde, Richard Albury, Tarmigan, Derek Mahar, Frode Aannevik, Keith Rarick, Andy Somerville, Ralf Recker, Øyvind A. Holm, Miklos Vajna, Sébastien Hinderer, Thomas Miedema, Joe Malin, and Tyler Breisacher contributed corrections and improvements.
 
 François Marier maintains the Debian package originally created by Daniel
 Baumann.
 
-JunJie, Meng, JiangWei, Rodrigo Toledo, and Leonardo Siqueira Rodrigues
-worked on translations of this guide.
+JunJie, Meng, JiangWei, Rodrigo Toledo, Leonardo Siqueira Rodrigues,
+Benjamin Bellee, and Armin Stebich worked on translations of this guide.
 
 My gratitude goes to many others for your support and praise. I'm tempted to
-quote you here, but it might raise expectations to ridiculous heights!
+quote you here, but it might raise expectations to ridiculous heights.
 
 If I've left you out by mistake, please tell me or just send me a patch!
 

en/secrets.txt

@@ -33,12 +33,10 @@ For every tracked file, Git records information such as its size, creation time
 Since stat calls are considerably faster than file reads, if you only edit a
 few files, Git can update its state in almost no time.
 
-We stated earlier that the index is a staging area. Then how can the index
-just be a bunch of file stats?
-
-The index can be thought of as a staging area because the add command puts
-files into Git's database and updates the index accordingly, while the commit
-command, without options, creates a commit based on the state of the index.
+We stated earlier that the index is a staging area. Why is a bunch of file
+stats a staging area? Because the add command puts files into Git's database
+and updates these stats, while the commit command, without options, creates a
+commit based only on these stats and the files already in the database.
 
 === Git's Origins ===
 

es/history.txt

@@ -59,7 +59,7 @@ En caso contrario, corre:
 
 Por lo tanto, es bueno hacer commits temprano y seguido: siempre se puede acomodar después usando rebase.
 
-=== Los Cambios Locales Al Final===
+=== Los Cambios Locales Al Final ===
 
 Estás trabajando en un proyecto activo. Haces algunos commits locales por un tiempo, y
 entonces sincronizas con el árbol oficial usando un merge. Este ciclo se repite unas
@@ -98,7 +98,7 @@ ejecutar más comandos filter-branch.
 Por último, reemplaza los clones de tu proyecto con tu versión
 revisada si pretendes interactuar con ellos en un futuro.
 
-=== Haciendo Historia===
+=== Haciendo Historia ===
 
 [[makinghistory]]
 ¿Quieres migrar un proyecto a Git? Si está siendo administrado con alguno de los sistemas más conocidos,