typos for ch.8,10,A,B,C

book/08-customizing-git/1-customizing-git.asc

@@ -1,4 +1,4 @@
-[[_customizing_git]]
+[[_customizing_git]]
 == Personalización de Git
 
 Hasta ahora, hemos visto los aspectos básicos del funcionamiento de Git y la
@@ -7,7 +7,7 @@ suministradas con Git para ayudarnos a usarlo de manera sencilla y eficiente.
 En este capítulo, avanzaremos sobre ciertas operaciones que puedes utilizar
 para personalizar el funcionamiento de Git ; presentando algunos de sus
 principales ajustes y el sistema de anclajes (hooks). Con estas operaciones,
-será facil conseguir que Git trabaje exactamente como tú, tu empresa o tu grupo
+será fácil conseguir que Git trabaje exactamente como tú, tu empresa o tu grupo
 necesitéis.
 
 include::sections/config.asc[]

book/08-customizing-git/sections/attributes.asc

@@ -1,20 +1,20 @@
-=== Git Attributes
+=== Git Attributes
 
 (((attributes)))
 Algunos de los ajustes que hemos visto, pueden ser especificados para un
-camino (path) concreto, de tal forma que Git los aplicará unicamente para
+camino (path) concreto, de tal forma que Git los aplicará únicamente para
 una carpeta o para un grupo de archivos determinado. Estos ajustes específicos
 relacionados con un camino, se denominan atributos en Git. Y se pueden fijar,
 bien mediante un archivo `.gitattribute` en uno de los directorios de tu
-proyecto (normalmente en la raiz del proyecto), o bien mediante el archivo
+proyecto (normalmente en la raíz del proyecto), o bien mediante el archivo
 `git/info/attributes` en el caso de no querer guardar el archivo de atributos
 dentro de tu proyecto.
 
 Por medio de los atributos, puedes hacer cosas tales como indicar diferentes
 estrategias de fusión para archivos o carpetas concretas de tu proyecto,
 decirle a Git cómo comparar archivos no textuales, o indicar a Git que filtre
 ciertos contenidos antes de guardarlos o de extraerlos del repositorio Git.
-En esta sección, aprenderas acerca de algunos atributos que puedes asignar
+En esta sección, aprenderás acerca de algunos atributos que puedes asignar
 a ciertos caminos (paths) dentro de tu proyecto Git, viendo algunos ejemplos
 de cómo utilizar sus funcionalidades de manera práctica.
 
@@ -23,12 +23,12 @@ de cómo utilizar sus funcionalidades de manera práctica.
 (((binary files)))
 Un buen truco donde utilizar los atributos Git es para indicarle cuáles de los
 archivos son binarios (en los casos en que Git no podría llegar a determinarlo
-por sí mismo), dándole a Git instruciones especiales sobre cómo tratar estos
+por sí mismo), dándole a Git instrucciones especiales sobre cómo tratar estos
 archivos. Por ejemplo, algunos archivos de texto se generan automáticamente y
 no tiene sentido compararlos; mientras que algunos archivos binarios sí que
 pueden ser comparados. Vamos a ver cómo indicar a Git cuál es cuál.
 
-===== Indentificación de archivos binarios
+===== Identificación de archivos binarios
 
 Algunos archivos aparentan ser textuales, pero a efectos prácticos merece más
 la pena tratarlos como binarios. Por ejemplo, los proyectos Xcode en un Mac
@@ -89,7 +89,7 @@ mejor utilizando los atributos Git. Poniendo lo siguiente en tu archivo
 ----
 
 Así decimos a Git que sobre cualquier archivo coincidente con el patrón
-indicado, (.docx), ha de utilizar el filtro ``word'' cuando intentente hacer
+indicado, (.docx), ha de utilizar el filtro ``word'' cuando intente hacer
 una comparación con él. ¿Qué es el filtro ``word''? Tienes que configurarlo
 tú mismo. Por ejemplo, puedes configurar Git para que utilice el programa
 `docx2txt` para convertir los documentos Word en archivos de texto planos,
@@ -148,8 +148,8 @@ mostrará) pero sirve en la mayoría de los casos.
 Otro problema donde puede ser útil esta técnica, es en la comparación de
 imágenes. Un camino puede ser pasar los archivos JPEG a través de un filtro
 para extraer su información EXIF (los metadatos que se graban dentro de la
-mayoria de formatos gráficos). Si te descargas e instalas el programa
-`exiftool`, puedes utilizarlo para convertir tus imagenes a textos
+mayoría de formatos gráficos). Si te descargas e instalas el programa
+`exiftool`, puedes utilizarlo para convertir tus imágenes a textos
 (metadatos), de tal forma que diff podrá al menos mostrarte algo útil de
 cualquier cambio que se produzca:
 
@@ -203,7 +203,7 @@ realizarlo.
 
 La primera, es inyectando automáticamente la suma de comprobación SHA-1
 de un gran objeto binario (blob) en un campo '$Id$' dentro del archivo. Si
-colocas este attributo en un archivo o conjunto de archivos, Git lo sustituirá
+colocas este atributo en un archivo o conjunto de archivos, Git lo sustituirá
 por la suma de comprobación SHA-1 la próxima vez que lo/s extraiga/s. Es
 importante destacar que no se trata de la suma SHA de la confirmación de
 cambios (commit), sino del propio objeto binario (blob):
@@ -320,7 +320,7 @@ $ echo 'date*.txt filter=dater' >> .gitattributes
 ----
 
 Al confirmar cambios (commit) y luego extraer (checkout) el archivo de vuelta,
-verás la clave sutituida:
+verás la clave sustituida:
 
 [source,console]
 ----
@@ -337,7 +337,7 @@ aplicaciones personalizadas. No obstante, debes de ser cuidadoso, ya que el
 archivo `.gitattibutes` se almacena y se transmite junto con el proyecto;
 pero no así el propio filtro, (en este caso, `dater`), sin el cual no puede
 funcionar. Cuando diseñes este tipo de filtros, han de estar pensados para
-que el proyecto continue funcionando correctamente incluso cuando fallen.
+que el proyecto continúe funcionando correctamente incluso cuando fallen.
 
 ==== Exportación del repositorio
 
@@ -396,7 +396,7 @@ Last commit date: $Format:Tue Apr 21 08:38:48 2009 -0700$
 
 (((merging, strategies)))
 También puedes utilizar los atributos Git para indicar distintas estrategias
-de fusión para archivos específicos de tu proyecto. Una opción muy util es
+de fusión para archivos específicos de tu proyecto. Una opción muy útil es
 la que nos permite indicar a Git que no intente fusionar ciertos archivos
 concretos cuando tengan conflictos, manteniendo en su lugar tus archivos
 sobre los de cualquier otro.

book/08-customizing-git/sections/config.asc

@@ -1,4 +1,4 @@
-[[_git_config]]
+[[_git_config]]
 === Configuración de Git
 
 (((git commands, config)))
@@ -17,7 +17,7 @@ Ahora vas a aprender un puñado de nuevas e interesantes opciones que puedes
 utilizar para personalizar el uso de Git.
 
 Primeramente, vamos a repasar brevemente los detalles de configuración de Git
-que ya has visto. Para determinar su comportamiento no estandar, Git emplea
+que ya has visto. Para determinar su comportamiento no estándar, Git emplea
 una serie de archivos de configuración. El primero de ellos es el archivo
 `/etc/gitconfig`, que contiene valores para todos y cada uno de los usuarios en
 el sistema y para todos sus repositorios. Con la opción `--system` del comando
@@ -47,10 +47,10 @@ comando `git config`.
 ==== Configuración básica del cliente
 
 Las opciones de configuración reconocidas por Git pueden distribuirse en dos
-grandes categorias: las del lado cliente y las del lado servidor. La mayoria
+grandes categorías: las del lado cliente y las del lado servidor. La mayoría
 de las opciones están en el lado cliente, – configurando tus preferencias
 personales de trabajo –. Aunque hay multitud de ellas, aquí vamos a ver
-solamente unas pocas, las más comunmente utilizadas o las que afectan
+solamente unas pocas, las más comúnmente utilizadas o las que afectan
 significativamente a tu forma de trabajar. No vamos a revisar aquellas opciones
 utilizadas solo en casos muy especiales. Si quieres consultar una lista
 completa, con todas las opciones contempladas en tu versión de Git, puedes
@@ -235,7 +235,7 @@ con el fin de que puedas abortar la operación auto-corregida con la opción
 
 (((color)))
 Git puede marcar con colores los resultados que muestra en tu terminal,
-ayudandote así a leerlos más facilmente. Hay unos cuantos parámetros que te
+ayudándote así a leerlos más fácilmente. Hay unos cuantos parámetros que te
 pueden ayudar a configurar tus colores favoritos.
 
 ===== `color.ui`
@@ -309,7 +309,7 @@ tus comandos. En estos ejemplos, voy a utilizar caminos y nombres Mac para
 los ejecutables; en otros sistemas, tendrás que sustituirlos por los
 correspondientes donde tengas instalado 'p4merge'. El primer script a
 preparar es uno al que denominaremos 'extMerge', para llamar al ejecutable con
-los correspodientes argumentos:
+los correspondientes argumentos:
 
 [source,console]
 ----
@@ -319,7 +319,7 @@ $ cat /usr/local/bin/extMerge
 ----
 
 El script para el comparador, ha de asegurarse de recibir siete argumentos
-y de pasar dos de ellos al script de fusion (merge). Por defecto, Git pasa los
+y de pasar dos de ellos al script de fusión (merge). Por defecto, Git pasa los
 siguientes argumentos al programa diff (comparador):
 
 [source]
@@ -455,7 +455,7 @@ $ git config --global merge.tool kdiff3
 
 Si utilizas este comando en lugar de preparar los archivos `extMerge`
 y `extDiff` antes comentados, Git utilizará KDiff3 para resolución
-de conflictos de integración y la herramienta estandar diff para
+de conflictos de integración y la herramienta estándar diff para
 las comparaciones.
 
 ==== Formateo y espacios en blanco
@@ -464,7 +464,7 @@ las comparaciones.
 El formato y los espacios en blanco son la fuente de los problemas
 más sutiles y frustrantes que muchos desarrolladores se pueden
 encontrar en entornos colaborativos, especialmente si son
-multi-plataforma. Es muy facil que algunos parches u otro trabajo
+multi-plataforma. Es muy fácil que algunos parches u otro trabajo
 recibido introduzcan sutiles cambios de espaciado, porque los editores
 suelen hacerlo inadvertidamente o, trabajando en entornos
 multi-plataforma, porque programadores Windows suelen añadir retornos
@@ -479,7 +479,7 @@ colaborando con gente que programa en Windows. Es muy posible que alguna
 vez te topes con problemas de finales de línea. Esto se debe a que
 Windows utiliza retorno-de-carro y salto-de-linea para marcar los finales
 de línea de sus archivos. Mientras que Mac y Linux utilizan solamente el
-caracter de salto-de-linea. Esta es una sutil, pero molesta, diferencia
+carácter de salto-de-linea. Esta es una sutil, pero molesta, diferencia
 cuando se trabaja en entornos multi-plataforma.
 
 Git la maneja convirtiendo automáticamente los finales CRLF en LF al
@@ -506,7 +506,7 @@ parámetro `core.autocrlf`:
 $ git config --global core.autocrlf input
 ----
 
-Este ajuste dejará los finales de línea CRLF en las extraciones de código
+Este ajuste dejará los finales de línea CRLF en las extracciones de código
 (checkout), pero dejará los finales LF en sistemas Mac o Linux, y en el
 repositorio.
 
@@ -522,7 +522,7 @@ $ git config --global core.autocrlf false
 ===== `core.whitespace`
 
 Git viene preajustado para detectar y resolver algunos de los problemas
-más tipicos relacionados con los espacios en blanco. Puede vigilar
+más típicos relacionados con los espacios en blanco. Puede vigilar
 acerca de seis tipos de problemas de espaciado: tres los tiene activados
 por defecto, pero se pueden desactivar; y tres vienen desactivados por
 defecto, pero se pueden activar.
@@ -540,7 +540,7 @@ que informa a Git de que los CR al final de las líneas son correctos.
 
 Puedes decir a Git cuales de ellos deseas activar o desactivar, ajustando
 el parámetro `core.whitespace` con los valores on/off separados por comas.
-Puedes desactivarlos tanto dejandolos fuera de la cadena de ajustes, como
+Puedes desactivarlos tanto dejándolos fuera de la cadena de ajustes, como
 añadiendo el prefijo `-` delante del valor. Por ejemplo, si deseas activar
 todos menos `cr-at-eol` puedes lanzar:
 
@@ -585,14 +585,14 @@ pero hay unas pocas interesantes que merecen ser tenidas en cuenta.
 ===== `receive.fsckObjects`
 
 Por defecto, Git no suele comprobar la consistencia de todos los
-objetos que recibe durante un envio (push), aunque Git tiene
+objetos que recibe durante un envío (push), aunque Git tiene
 la capacidad para asegurarse de que cada objeto sigue casando
 con su suma de control SHA-1 y sigue apuntando a objetos válidos.
 No lo suele hacer en todos y cada uno de los envíos (push). Es una
 operación costosa, que, dependiendo del tamaño del repositorio,
 puede llegar a añadir mucho tiempo a cada operación de envío (push).
 De todas formas, si deseas que Git compruebe la consistencia de todos
-los objetos en todos los envios, puedes forzarle a hacerlo ajustando
+los objetos en todos los envíos, puedes forzarle a hacerlo ajustando
 a 'true' el parámetro `receive.fsckObjects`:
 
 [source,console]
@@ -609,12 +609,12 @@ Si reorganizas (rebase) confirmaciones de cambio (commit) que ya habías
 enviado y tratas de enviarlas (push) de nuevo; o si intentas enviar una
 confirmación a una rama remota que no contiene la confirmación actualmente
 apuntada por la rama, normalmente, la operación te será denegada por
-la rama remota sobre la que pretendias realizarla. Habitualmente, este
+la rama remota sobre la que pretendías realizarla. Habitualmente, este
 es el comportamiento más adecuado. Pero, en el caso de las reorganizaciones,
-cuando estás totalmente seguro de lo que haces, puedes forzar el envio,
+cuando estás totalmente seguro de lo que haces, puedes forzar el envío,
 utilizando la opción `-f` en el comando `git push` a la rama remota.
 
-Para impedir estos envios forzados de referencias de avance no
+Para impedir estos envíos forzados de referencias de avance no
 directo (no fast-forward) a ramas remotas, es para lo que se emplea
 el parámetro `receive.denyNonFastForwards`:
 
@@ -625,7 +625,7 @@ $ git config --system receive.denyNonFastForwards true
 
 Otra manera de obtener el mismo resultado, es a través de los enganches
 (hooks) en el lado servidor, enganches de los que hablaremos en breve. Esta
-otra vía te permite realizar ajustes más finos, tales como denegar refencias
+otra vía te permite realizar ajustes más finos, tales como denegar referencias
 de avance no directo, (non-fast-forwards), únicamente a un grupo de usuarios.
 
 ===== `receive.denyDeletes`

book/08-customizing-git/sections/hooks.asc

@@ -1,9 +1,9 @@
-[[_git_hooks]]
+[[_git_hooks]]
 === Puntos de enganche en Git
 
 (((hooks)))
 Al igual que en otros sistemas de control de versiones, Git también cuenta
-con mecanismos para lanzar scrips de usuario cuando suceden ciertas acciones
+con mecanismos para lanzar scripts de usuario cuando suceden ciertas acciones
 importantes, llamados puntos de enganche (hooks). Hay dos grupos de esos
 puntos de lanzamiento: los del lado
 cliente y los del lado servidor. Los puntos del lado cliente están relacionados
@@ -56,10 +56,10 @@ Primero se activa el punto de enganche `pre-commit`, incluso antes de que
 teclees el mensaje de confirmación. Se suele utilizar para inspeccionar
 la instantánea (snapshot) que vas a confirmar, para ver si has olvidado
 algo, para asegurar que las pruebas se ejecutan, o para revisar cualquier
-aspecto que necesites inspeccionar en el codigo. Saliendo con un valor
+aspecto que necesites inspeccionar en el código. Saliendo con un valor
 de retorno distinto de cero, se aborta la confirmación de cambios. Aunque
-siempre puedes saltartelo con la orden `git commit --no-verify`. Puede ser
-util para realizar tareas tales como revisar el estilo del código
+siempre puedes saltártelo con la orden `git commit --no-verify`. Puede ser
+útil para realizar tareas tales como revisar el estilo del código
 (lanzando `lint` o algo equivalente), revisar los espacios en blanco de
 relleno (el script de ejemplo hace exactamente eso), o revisar si todos
 los nuevos métodos llevan la adecuada documentación.
@@ -74,8 +74,8 @@ clave SHA-1 si estamos enmendando un commit existente. Este punto de enganche
 no tiene mucha utilidad para las confirmaciones de cambios normales; pero sí
 para las confirmaciones donde el mensaje por defecto es autogenerado, como
 en las confirmaciones de fusiones (merge), los mensajes con plantilla, las
-confirmaciones aplastadas (squash), o las confirmaciones de correccion
-(amend). Se puede utilizar combinandolo con una plantilla de confirmación,
+confirmaciones aplastadas (squash), o las confirmaciones de corrección
+(amend). Se puede utilizar combinándolo con una plantilla de confirmación,
 para poder insertar información automáticamente.
 
 El punto de enganche `commit-msg` recibe un parámetro: la ubicación
@@ -87,9 +87,9 @@ la última parte de este capítulo, veremos cómo podemos utilizar este punto
 de enganche para revisar si el mensaje de confirmación es conforme a un
 determinado patrón obligatorio.
 
-Despues de completar todo el proceso de confirmación de cambios, es cuando
+Después de completar todo el proceso de confirmación de cambios, es cuando
 se lanza el punto de enganche `post-commit`. Este no recibe ningún parámetro,
-pero podemos obtener facilmente la última confirmación de cambios con el
+pero podemos obtener fácilmente la última confirmación de cambios con el
 comando `git log -1 HEAD`. Habitualmente, este script final se suele utilizar
 para realizar notificaciones o tareas similares.
 
@@ -114,7 +114,7 @@ El siguiente punto de enganche que se activa al aplicar parches con `git am` es
 el punto `pre-applypatch`. No recibe ningún argumento de entrada y se lanza
 después de que el parche haya sido aplicado, por lo que puedes utilizarlo para
 revisar la situación (snapshot) antes de confirmarla. Con este script, puedes
-lanzar pruebas o similares para chequear el arbol de trabajo. Si falta algo o
+lanzar pruebas o similares para chequear el árbol de trabajo. Si falta algo o
 si alguna de las pruebas falla, saliendo con un código de salida distinto de
 cero abortará el comando `git am` sin confirmar el parche.
 
@@ -173,15 +173,15 @@ operación, o para poderla abortar si se considera que no es un buen momento.
 Aparte de los puntos del lado cliente, como administrador de sistemas, puedes
 utilizar un par de puntos de enganche importantes en el lado servidor; para
 implementar prácticamente cualquier tipo de política que quieras mantener en tu
-proyecto. Estos scripts se lanzan antes y después de cada envio (push) al
+proyecto. Estos scripts se lanzan antes y después de cada envío (push) al
 servidor. El script previo, puede terminar con un código de salida distinto de
-cero y abortar el envio, devolviendo el correspondiente mensaje de error al
+cero y abortar el envío, devolviendo el correspondiente mensaje de error al
 cliente. Este script puede implementar políticas de recepción tan complejas
 como desees.
 
 ===== `pre-receive`
 
-El primer script que se activa al manejar un envio de un cliente es el
+El primer script que se activa al manejar un envío de un cliente es el
 correspondiente al punto de enganche `pre-receive`. Recibe una lista de
 referencias que se están enviando (push) desde la entrada estándar (stdin); y,
 si termina con un código de salida distinto de cero, ninguna de ellas será
@@ -214,6 +214,6 @@ la de alimentar una lista de correo-e, avisar a un servidor de integración
 continua, o actualizar un sistema de seguimiento de tickets de servicio
 (pudiendo incluso procesar el mensaje de confirmación para ver si hemos de
 abrir, modificar o dar por cerrado algún ticket). Este script no puede detener
-el proceso de envio, pero el cliente no se desconecta hasta que no se completa
+el proceso de envío, pero el cliente no se desconecta hasta que no se completa
 su ejecución; por tanto, has de ser cuidadoso cuando intentes realizar con él
 tareas que puedan requerir mucho tiempo.