Fix book compilation

A-git-in-other-environments.asc

@@ -1,10 +1,11 @@
-[#A-git-in-other-environments]
 [appendix]
+[#A-git-in-other-environments]
 == Git en otros entornos
 
 Si has leído hasta aquí todo el libro, seguro que has aprendido un montón de cosas sobre el uso de Git con la línea de comandos.
 Se puede trabajar con archivos locales, conectar nuestro repositorio con otros repositorios en la red y realizar nuestro trabajo eficientemente con ellos. Aunque las opciones no terminan ahí, Git se utiliza con parte de un ecosistema mayor y un terminal no siempre es la mejor forma de trabajar.
 Vamos a ver otros tipos de entornos en los que Git resulta muy útil y cómo otras aplicaciones (incluidas las tuyas) pueden trabajar conjuntamente con Git.
+
 ////
 If you read through the whole book, you've learned a lot about how to use Git at the command line.
 You can work with local files, connect your repository to others over a network, and work effectively with others.

B-embedding-git.asc

@@ -2,7 +2,7 @@
 [appendix]
 == Integrando Git en tus Aplicaciones
 
-Si tu aplicación es para desarrolladores, es muy probable que pueda beneficiarse de la integración con el control de código fuente. 
+Si tu aplicación es para desarrolladores, es muy probable que pueda beneficiarse de la integración con el control de código fuente.
 Incluso las aplicaciones que no sean para desarrolladores, tales como editores de documentos, podrían beneficiarse de las características de control de versiones, y el modelo de Git funciona muy bien para muchos escenarios diferentes.
 
 Si necesitas integrar Git con tu aplicación, tienes básicamente tres opciones: generar un shell y usar la herramienta de línea de comandos de Git; Libgit2; y JGit.

C-git-commands.asc

@@ -1,12 +1,11 @@
 [#C-git-commands]
-[appendix]
+[appendix]
 == Comandos de Git
 
-A lo largo del libro hemos introducido docenas de comandos de Git y nos hemos esforzado para introducirlos dentro de una especie de narrativa, añadiendo más comandos a la historia poco a poco. Sin embargo, esto nos deja con ejemplos de uso de los comandos algo dispersos por todo el libro. 
+A lo largo del libro hemos introducido docenas de comandos de Git y nos hemos esforzado para introducirlos dentro de una especie de narrativa, añadiendo más comandos a la historia poco a poco. Sin embargo, esto nos deja con ejemplos de uso de los comandos algo dispersos por todo el libro.
 
 En este apéndice, repasaremos todos los comandos de Git que hemos tratado a lo largo del libro, agrupados por el uso que se les ha dado. Vamos a hablar de lo que hace cada comando de manera muy general y a continuación señalaremos en qué parte del libro puedes encontrar un uso de él.
 
-
 === Configuración
 
 Hay dos comandos que se usan bastante, desde las primeras invocaciones de Git hasta el ajuste y referenciamiento diario, los comandos `config` y `help`.
@@ -64,7 +63,7 @@ En <<ch04-git-server#r_git_on_the_server>> nos fijamos en el uso de la opción `
 
 En <<ch07-git-tools#r_bundling>> lo usamos para desempaquetar un repositorio Git empaquetado (bundle).
 
-Finalmente, en <<ch07-git-tools#r_cloning_submodules>> aprendemos la opción `--recursive` para realizar la clonación de un repositorio con submódulos un poco más simple. 
+Finalmente, en <<ch07-git-tools#r_cloning_submodules>> aprendemos la opción `--recursive` para realizar la clonación de un repositorio con submódulos un poco más simple.
 
 Aunque se usa en muchos otros lugares a través del libro, estos son los que son algo únicos o donde se utiliza en formas que son un poco diferentes.
 
@@ -111,7 +110,7 @@ Finalmente, lo usamos para realmente comparar cambios en submódulos con `--subm
 
 El comando `git difftool` simplemente lanza una herramienta externa para mostrar la diferencia entre dos árboles, en caso de que desees utilizar algo que no sea el comando`git diff` incorporado.
 
-Mencionamos sólo brevemente esto en <<_git_diff_staged >>.
+Mencionamos sólo brevemente esto en <<ch02-git-basics#r_git_diff_staged>>.
 
 ==== git commit
 
@@ -139,9 +138,9 @@ Utilizamos `git reset --hard` para abortar una fusión en <<ch07-git-tools#r_abo
 
 ==== git rm
 
-El comando `git rm` se utiliza para eliminar archivos del área de ensayo y el directorio de trabajo para Git. Es similar a `git add` en que pone en escena una eliminación de un archivo para la próxima confirmación. 
+El comando `git rm` se utiliza para eliminar archivos del área de ensayo y el directorio de trabajo para Git. Es similar a `git add` en que pone en escena una eliminación de un archivo para la próxima confirmación.
 
-Cubrimos el comando `git rm` con cierto detalle en <<_removing_files >>, incluyendo la eliminación de archivos de forma recursiva y sólo la eliminación de archivos desde el área de ensayo, pero dejándolos en el directorio de trabajo con `--cached`.
+Cubrimos el comando `git rm` con cierto detalle en <<ch02-git-basics#r_removing_files>>, incluyendo la eliminación de archivos de forma recursiva y sólo la eliminación de archivos desde el área de ensayo, pero dejándolos en el directorio de trabajo con `--cached`.
 
 El único otro uso diferente de `git rm` en el libro está en <<ch10-git-internals#r_removing_objects>>, donde utilizamos brevemente y explicamos el `--ignore-unmatch` al ejecutar `git filter-branch`, el cual simplemente hace que no salga un error cuando el archivo que estamos tratando de eliminar no existe. Esto puede ser útil para fines de scripting.
 
@@ -192,7 +191,7 @@ La herramienta `git merge` se utiliza para fusionar uno o más ramas dentro de l
 
 El comando `git merge` fue introducido por primera en <<ch03-git-branching#r_basic_branching>>. A pesar de que se utiliza en diversos lugares en el libro, hay muy pocas variaciones del comando `merge` -- en general, sólo `git merge <branch>` con el nombre de la rama individual que se desea combinar.
 
-Cubrimos cómo hacer una fusión aplastada (squashed merge) (donde Git fusiona el trabajo, pero finge como si fuera simplemente un nuevo commit sin registrar la historia de la rama que se está fusionando) al final de <<ch05-distributed-git#r_public_project>>. 
+Cubrimos cómo hacer una fusión aplastada (squashed merge) (donde Git fusiona el trabajo, pero finge como si fuera simplemente un nuevo commit sin registrar la historia de la rama que se está fusionando) al final de <<ch05-distributed-git#r_public_project>>.
 
 Repasamos mucho sobre el proceso de fusión y dirección, incluyendo el comando `-Xignore-all-whitespace` y el indicador `--abort` para abortar un problema de fusión en <<ch07-git-tools#r_advanced_merging>>.
 
@@ -218,11 +217,11 @@ En <<ch03-git-branching#r_create_new_branch>> lo utilizamos con la opción `--de
 
 En <<ch05-distributed-git#r_private_team>> y <<ch07-git-tools#r_commit_ranges>> cubrimos la sintaxis `branchA..branchB` al usar el comando `git log` para ver que commits son únicos a una rama en relación a otra rama. En <<ch07-git-tools#r_commit_ranges>> repasamos esto bastante extensamente.
 
-En <<ch07-git-tools#r_merge_log>> y <<ch07-git-tools#r_triple_dot>> cubrimos el uso del formato `branchA...branchB` y la sintaxis `--left-right` para ver que está en una rama o en la otra pero no en ambas. En <<ch07-git-tools#r_merge_log>> también vemos como utilizar la opción `--merge` para ayudarnos con la depuración de conflictos de fusión así como el uso de la opción `--cc` para ver conflictos de fusión en tu historia. 
+En <<ch07-git-tools#r_merge_log>> y <<ch07-git-tools#r_triple_dot>> cubrimos el uso del formato `branchA...branchB` y la sintaxis `--left-right` para ver que está en una rama o en la otra pero no en ambas. En <<ch07-git-tools#r_merge_log>> también vemos como utilizar la opción `--merge` para ayudarnos con la depuración de conflictos de fusión así como el uso de la opción `--cc` para ver conflictos de fusión en tu historia.
 
 En <<ch07-git-tools#r_git_reflog>> usamos la opción `-g` para ver el reflog de Git a través de esta herramienta en lugar de hacer un recorrido de la rama.
 
-En <<ch07-git-tools#r_searching>> vemos el uso de las opciones `-S` y `-L` para hacer búsquedas bastante sofisticados de algo que sucedió históricamente en el código como ver la historia de una función. 
+En <<ch07-git-tools#r_searching>> vemos el uso de las opciones `-S` y `-L` para hacer búsquedas bastante sofisticados de algo que sucedió históricamente en el código como ver la historia de una función.
 
 En <<ch07-git-tools#r_signing_commits>> vemos como usar `--show-signature` para añadir una cadena de texto de validación a cada commit en la salida de `git log` basado en si fue válidadmente firmado o no.
 
@@ -301,7 +300,7 @@ Usamos `git archive` para crear un tarball de un proyecto para su compartición
 
 ==== git submodule
 
-El comando `git submodule` se utiliza para gestionar repositorios externos dentro de repositorios normales. 
+El comando `git submodule` se utiliza para gestionar repositorios externos dentro de repositorios normales.
 Esto podría ser por bibliotecas u otros tipos de recursos compartidos. El comando `submodule` tiene varios sub-commandos (`add`, `update`, `sync`, etc) para la gestión de estos recursos.
 
 Este comando es sólo mencionado y cubierto enteramente en <<ch07-git-tools#r_git_submodules>>.
@@ -338,7 +337,7 @@ Git tiene un par de comandos que se utilizan para ayudar a depurar un problema e
 
 ==== git bisect
 
-La herramienta `git bisect` es una herramienta de depuración increíblemente útil, utilizada para encontrar qué commit específico fue el primero en introducir un bug o problema, haciendo una búsqueda binaria automática. 
+La herramienta `git bisect` es una herramienta de depuración increíblemente útil, utilizada para encontrar qué commit específico fue el primero en introducir un bug o problema, haciendo una búsqueda binaria automática.
 
 Está completamente cubierto de <<ch07-git-tools#r_binary_search>> y sólo se menciona en esa sección.
 
@@ -366,9 +365,9 @@ Esto se describe y se muestra en <<ch05-distributed-git#r_rebase_cherry_pick>>.
 
 ==== git rebase
 
-El comando `git rebase` es básicamente un `cherry-pick` automatizado. Determina una serie de commits y luego los escoge uno a uno en el mismo orden en otro lugar. 
+El comando `git rebase` es básicamente un `cherry-pick` automatizado. Determina una serie de commits y luego los escoge uno a uno en el mismo orden en otro lugar.
 
-El rebasing se cubre en detalle en <<ch03-git-branching#r_rebasing>>,  inclusive cubriendo las incidencias de colaboración involucradas con el rebasing de ramas que ya son públicas. 
+El rebasing se cubre en detalle en <<ch03-git-branching#r_rebasing>>,  inclusive cubriendo las incidencias de colaboración involucradas con el rebasing de ramas que ya son públicas.
 
 Lo usamos en la práctica durante un ejemplo de dividir la historia en dos repositorios separados en <<ch07-git-tools#r_replace>>, utilizando el indicador `--onto` también.
 
@@ -428,9 +427,9 @@ Git viene con unos pocos comandos para integrarse con otros sistemas de control
 
 ==== git svn
 
-El comando `git svn` se utiliza para comunicarnos como cliente con el sistema de control de versiones Subversion. 
+El comando `git svn` se utiliza para comunicarnos como cliente con el sistema de control de versiones Subversion.
 
-Esto significa que puedes usar Git para obtener desde y enviar a un servidor Subversion. 
+Esto significa que puedes usar Git para obtener desde y enviar a un servidor Subversion.
 
 Este comando es cubierto en profundidad en <<ch09-git-and-other-scms#r_git_svn>>.
 
@@ -469,7 +468,7 @@ También repasamos un ejemplo práctico de la recuperación de tal rama perdida
 
 El comando `git filter-branch` se utiliza para reescribir un montón de commits de acuerdo a ciertos patrones, como la eliminación de un archivo de todas partes o el filtrado de todo el repositorio a un solo subdirectorio para sacar un proyecto.
 
-En <<ch07-git-tools#r_removing_file_every_commit>> explicamos el comando y exploramos varias opciones diferentes, tales como `--commit-filter`, `--subdirectory-filter` y `--tree-filter`. 
+En <<ch07-git-tools#r_removing_file_every_commit>> explicamos el comando y exploramos varias opciones diferentes, tales como `--commit-filter`, `--subdirectory-filter` y `--tree-filter`.
 
 En <<ch09-git-and-other-scms#r_git_p4>> y <<ch09-git-and-other-scms#r_git_tfs>> lo usamos para arreglar repositorios externos importados.
 

Gemfile

@@ -14,7 +14,7 @@ gem 'asciidoctor-pdf-cjk-kai_gen_gothic', '~> 0.1.1'
 gem 'coderay'
 gem 'pygments.rb'
 gem 'thread_safe'
-gem 'epubcheck-ruby'
+gem 'epubcheck'
 gem 'kindlegen'
 
 gem 'octokit'

Gemfile.lock

@@ -52,7 +52,7 @@ GEM
     concurrent-ruby (1.0.5)
     css_parser (1.6.0)
       addressable
-    epubcheck-ruby (4.0.2.1)
+    epubcheck (3.0.1)
     faraday (0.14.0)
       multipart-post (>= 1.2, < 3)
     faraday-http-cache (2.0.0)
@@ -126,7 +126,7 @@ DEPENDENCIES
   asciidoctor-pdf-cjk-kai_gen_gothic (~> 0.1.1)
   awesome_print
   coderay
-  epubcheck-ruby
+  epubcheck
   github_changelog_generator!
   json
   kindlegen

book/01-introduction/sections/basics.asc

@@ -14,7 +14,7 @@ Git no maneja ni almacena sus datos de esta forma.  Git maneja sus datos como un
 .Almacenamiento de datos como instantáneas del proyecto a través del tiempo.
 image::images/snapshots.png[Git stores data as snapshots of the project over time.]
 
-Esta es una diferencia importante entre Git y prácticamente todos los demás VCS.  Hace que Git reconsidere casi todos los aspectos del control de versiones que muchos de los demás sistemas copiaron de la generación anterior.  Esto hace que Git se parezca más a un sistema de archivos miniatura con algunas herramientas tremendamente poderosas desarrolladas sobre él, que a un VCS.  Exploraremos algunos de los beneficios que obtienes al modelar tus datos de esta manera cuando veamos ramificación (branching) en Git en el (véase <<ch03-git-branching#ch03-git-branching>>) (véase el link:../../03-git-branching/1-git-branching.asc[Capítulo 3]). FIXME
+Esta es una diferencia importante entre Git y prácticamente todos los demás VCS.  Hace que Git reconsidere casi todos los aspectos del control de versiones que muchos de los demás sistemas copiaron de la generación anterior.  Esto hace que Git se parezca más a un sistema de archivos miniatura con algunas herramientas tremendamente poderosas desarrolladas sobre él, que a un VCS.  Exploraremos algunos de los beneficios que obtienes al modelar tus datos de esta manera cuando veamos ramificación (branching) en Git en el (véase <<ch03-git-branching#ch03-git-branching>>).
 
 ==== Casi todas las operaciones son locales
 
@@ -41,7 +41,7 @@ Verás estos valores hash por todos lados en Git porque son usados con mucha fre
 
 Cuando realizas acciones en Git, casi todas ellas solo añaden información a la base de datos de Git.  Es muy difícil conseguir que el sistema haga algo que no se pueda enmendar, o que de algún modo borre información.  Como en cualquier VCS, puedes perder o estropear cambios que no has confirmado todavía.  Pero después de confirmar una copia instantánea en Git es muy difícil de perderla, especialmente si envías tu base de datos a otro repositorio con regularidad.
 
-Esto hace que usar Git sea un placer, porque sabemos que podemos experimentar sin peligro de estropear gravemente las cosas.  Para un análisis más exhaustivo de cómo almacena Git su información y cómo puedes recuperar datos aparentemente perdidos, ver <<ch02-git-basics#r_undoing>> link:../../02-git-basics/sections/undoing.asc[Capítulo 2]. FIXME
+Esto hace que usar Git sea un placer, porque sabemos que podemos experimentar sin peligro de estropear gravemente las cosas.  Para un análisis más exhaustivo de cómo almacena Git su información y cómo puedes recuperar datos aparentemente perdidos, ver <<ch02-git-basics#r_undoing>>.
 
 ==== Los Tres Estados
 
@@ -64,4 +64,4 @@ El flujo de trabajo básico en Git es algo así:
 2. Preparas los archivos, añadiéndolos a tu área de preparación.
 3. Confirmas los cambios, lo que toma los archivos tal y como están en el área de preparación y almacena esa copia instantánea de manera permanente en tu directorio de Git.
 
-Si una versión concreta de un archivo está en el directorio de Git, se considera confirmada (committed).  Si ha sufrido cambios desde que se obtuvo del repositorio, pero ha sido añadida al área de preparación, está preparada (staged).  Y si ha sufrido cambios desde que se obtuvo del repositorio, pero no se ha preparado, está modificada (modified).  En el <<ch02-git-basics#ch02-git-basics>> link:../../02-git-basics[Capítulo 2] aprenderás más acerca de estos estados y de cómo puedes aprovecharlos o saltarte toda la parte de preparación.
+Si una versión concreta de un archivo está en el directorio de Git, se considera confirmada (committed).  Si ha sufrido cambios desde que se obtuvo del repositorio, pero ha sido añadida al área de preparación, está preparada (staged).  Y si ha sufrido cambios desde que se obtuvo del repositorio, pero no se ha preparado, está modificada (modified).  En <<ch02-git-basics#ch02-git-basics>> aprenderás más acerca de estos estados y de cómo puedes aprovecharlos o saltarte toda la parte de preparación.

book/01-introduction/sections/history.asc

@@ -12,4 +12,4 @@ En el 2005, la relación entre la comunidad que desarrollaba el kernel de Linux
 *  Completamente distribuido
 *  Capaz de manejar grandes proyectos (como el kernel de Linux) eficientemente (velocidad y tamaño de los datos)
 
-Desde su nacimiento en el 2005, Git ha evolucionado y madurado para ser fácil de usar y conservar sus características iniciales.  Es tremendamente rápido, muy eficiente con grandes proyectos, y tiene un increíble sistema de ramificación (branching) para desarrollo no lineal (véase <<ch03-git-branching#ch03-git-branching>>) (véase el link:../../03-git-branching/1-git-branching.asc[Capítulo 3]). FIXME
+Desde su nacimiento en el 2005, Git ha evolucionado y madurado para ser fácil de usar y conservar sus características iniciales.  Es tremendamente rápido, muy eficiente con grandes proyectos, y tiene un increíble sistema de ramificación (branching) para desarrollo no lineal (véase <<ch03-git-branching#ch03-git-branching>>)

book/01-introduction/sections/installing.asc

@@ -2,7 +2,7 @@
 
 Antes de empezar a utilizar Git, tienes que instalarlo en tu computadora.  Incluso si ya está instalado, este es posiblemente un buen momento para actualizarlo a su última versión.  Puedes instalarlo como un paquete, a partir de un archivo instalador, o bajando el código fuente y compilándolo tú mismo.
 
-[NOTA]
+[NOTE]
 ====
 Este libro fue escrito utilizando la versión *2.0.0* de Git.  Aun cuando la mayoría de comandos que usaremos deben funcionar en versiones más antiguas de Git, es posible que algunos de ellos no funcionen o funcionen ligeramente diferente si estás utilizando una versión anterior de Git.  Debido a que Git es particularmente bueno en preservar compatibilidad hacia atrás, cualquier versión posterior a 2.0 debe funcionar bien.
 ====

book/03-git-branching/sections/remote-branches.asc

@@ -15,7 +15,7 @@ Supongamos que tienes un servidor Git en tu red, en `git.ourcompany.com`.
 Si haces un clon desde ahí, Git automáticamente lo denominará `origin`, traerá (pull) sus datos, creará un apuntador hacia donde esté en ese momento su rama `master` y denominará la copia local `origin/master`.
 Git te proporcionará también tu propia rama `master`, apuntando al mismo lugar que la rama `master` de `origin`; de manera que tengas donde trabajar.
 
-[NOTA]
+[NOTE]
 .``origin'' no es especial
 ====
 Así como la rama ``master'' no tiene ningún significado especial en Git, tampoco lo tiene ``origin''. ``master'' es un nombre muy usado solo porque es el nombre por defecto que Git le da a la rama inicial cuando ejecutas `git init`. De la misma manera, ``origin'' es el nombre por defecto que Git le da a un remoto cuando ejecutas `git clone`. Si en cambio ejecutases `git clone -o booyah`, tendrías una rama `booyah/master` como rama remota por defecto.(((origin)))