Merge pull request #145 from DiegoFRamirez/new_corrections

Some minors changes in section '08-customizing-git'

Author: andres-mancera

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

@@ -88,11 +88,11 @@ mejor utilizando los atributos Git. Poniendo lo siguiente en tu archivo
 *.docx diff=word
 ----
 
-Así decimos a Git que sobre cualquier archivo coincidente con el patrón
+Así le decimos a Git que sobre cualquier archivo coincidente con el patrón
 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,
+`docx2txt` para convertir los documentos Word en archivos de texto plano,
 archivos sobre los que poder realizar comparaciones sin problemas.
 
 En primer lugar, necesitas instalar `docx2txt`, obteniéndolo de:
@@ -148,9 +148,9 @@ 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
-mayoría de formatos gráficos). Si te descargas e instalas el programa
+mayoría de los 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
+(metadatos), de tal forma que el comando ``diff'' podrá, al menos, mostrarte algo útil de
 cualquier cambio que se produzca:
 
 [source,console]
@@ -227,7 +227,7 @@ $Id: 42812b7653c7b88933f8a9d6cad0ca16714b9bb3 $
 
 Pero esto tiene un uso bastante limitado. Si has utilizado alguna vez las
 sustituciones de CVS o de Subversion, sabrás que pueden incluir una marca de
-fecha (la suma de comprobación SHA no es igual de util, ya que, por ser
+fecha (la suma de comprobación SHA no es igual de útil, ya que, por ser
 bastante aleatoria, es imposible deducir si una suma SHA es anterior o
 posterior a otra).
 
@@ -276,7 +276,7 @@ filtrar todo el código fuente C a través de `indent` antes de confirmar
 cambios en él.
 
 Otro ejemplo interesante es el de poder conseguir una expansión de la clave
-`$Date$` del estilo de RCS. Para hacerlo, necesitas un pequeño script que
+`$Date$` del estilo de **RCS**. Para hacerlo, necesitas un pequeño script que
 coja el nombre de un archivo, localice la fecha de la última confirmación
 de cambios en el proyecto, e inserte dicha información en el archivo. Este
 podria ser un pequeño script Ruby para hacerlo:
@@ -291,7 +291,7 @@ puts data.gsub('$Date$', '$Date: ' + last_date.to_s + '$')
 
 Simplemente, utiliza el comando `git log` para obtener la fecha de la
 última confirmación de cambios, y sustituye con ella todas las cadenas
-`$Date$` que encuentre en el flujo de entrada stdin; imprimiendo luego los
+`$Date$` que encuentre en el flujo de entrada ``stdin''; imprimiendo luego los
 resultados. Debería de ser sencillo de implementarlo en cualquier otro
 lenguaje que domines.
 
@@ -429,6 +429,5 @@ Auto-merging database.xml
 Merge made by recursive.
 ----
 
-Y el archivo `database.xml` permanecerá inalterado en cualquier que fuera la
+Y el archivo `database.xml` permanecerá inalterado en cualquiera que fuera la
 versión que tenias originalmente.
-

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

@@ -5,7 +5,7 @@
 Como se ha visto brevemente en <<ch01-introduction#ch01-introduction>>, podemos acceder a los
 ajustes de configuración de Git a través del comando 'git config'. Una de las
 primeras acciones que has realizado con Git ha sido el configurar tu nombre
-y tu dirección de correo-e.
+y tu dirección de correo electrónico.
 
 [source,console]
 ----
@@ -178,7 +178,7 @@ $ git tag -s <tag-name>
 ===== `core.excludesfile`
 
 (((excludes)))(((.gitignore)))
-Se pueden indicar expresiones en el archivo '.gitignore' de tu proyecto para
+Se pueden indicar expresiones regulares en el archivo '.gitignore' de tu proyecto para
 indicar a Git lo que debe considerar o no como archivos sin seguimiento, o lo
 que interará o no seleccionar cuando lances el comando 'git add', tal y como
 se indicó en <<ch02-git-basics#r_ignoring>>.
@@ -289,23 +289,23 @@ También puedes aplicar atributos tales como `bold` (negrita), `dim` (tenue),
 ==== Herramientas externas para fusión y diferencias
 
 (((mergetool)))(((difftool)))
-Aunque Git lleva una implementación interna de diff, la que se utiliza
+Aunque Git lleva una implementación interna de ``diff'', la que se utiliza
 habitualmente, se puede sustituir por una herramienta externa. Puedes
 incluso configurar una herramienta gráfica para la resolución de
-conflictos, en lugar de resolverlos manualmente. Lo voy a demostrar
+conflictos, en lugar de resolverlos manualmente. Vamos a demostrarlo
 configurando Perforce Visual Merge (P4Merge) como herramienta para realizar
 las comparaciones y resolver conflictos; ya que es una buena herramienta
 gráfica y es libre.
 
 Si lo quieres probar, P4Merge funciona en todas las principales plataformas.
-Los nombres de carpetas que utilizaré en los ejemplos funcionan en sistemas
+Los nombres de carpetas que utilizaremos en los ejemplos funcionan en sistemas
 Mac y Linux; para Windows, tendrás que sustituir '/usr/local/bin' por el
 correspondiente camino al ejecutable en tu sistema.
 
 P4Merge se puede descargar desde http://www.perforce.com/downloads/Perforce/[].
 
 Para empezar, tienes que preparar los correspondientes scripts para lanzar
-tus comandos. En estos ejemplos, voy a utilizar caminos y nombres Mac para
+tus comandos. En estos ejemplos, vamos 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
@@ -386,13 +386,13 @@ $ git diff 32d1776b1^ 32d1776b1
 ----
 
 En lugar de mostrar las diferencias por línea de comandos, Git
-lanzará P4Merge, que tiene una pinta como:
+lanzará P4Merge, que tiene un aspecto como:
 
 .P4Merge.
 image::images/p4merge.png[P4Merge.]
 
 Si intentas fusionar (merge) dos ramas y tienes los consabidos
-conflictos de integración, puedes lanzar el comando `git mergetool`;
+conflictos de integración, puedes lanzar el comando `git mergetool` que a su vez
 lanzará P4Merge para ayudarte a resolver los conflictos por medio
 de su interfaz gráfica.
 
@@ -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 estándar diff para
+de conflictos de integración y la herramienta estándar ``diff'' para
 las comparaciones.
 
 ==== Formateo y espacios en blanco

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

@@ -6,7 +6,7 @@ Al igual que en otros sistemas de control de versiones, Git también cuenta
 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
+cliente y los del lado servidor. Los puntos de enganche del lado cliente están relacionados
 con operaciones tales como la confirmación de cambios (commit) o la fusión
 (merge). Los del lado servidor están relacionados con operaciones tales como
 la recepción de contenidos enviados (push) a un servidor. Estos puntos de
@@ -42,7 +42,7 @@ de correo electrónico y todos los demás.
 [NOTE]
 ====
 Observa que los puntos de enganche del lado del cliente *no se copian* cuando
-clonas el repositorio. Si quieres que tengan un efecto para forzar una política
+clonas el repositorio. Si quieres que tengan un efecto para forzar una política específica
 es necesario que esté en el lado del cliente. Por ejemplo, mira en
 <<r_an_example_git_enforced_policy>>.
 ====
@@ -70,7 +70,7 @@ el mensaje por defecto. Te permite editar el mensaje por defecto, antes
 de que lo vea el autor de la confirmación de cambios. Este punto de
 enganche recibe varias entradas: la ubicación (path) del archivo temporal
 donde se almacena el mensaje de confirmación, el tipo de confirmación y la
-clave SHA-1 si estamos enmendando un commit existente. Este punto de enganche
+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
@@ -100,7 +100,7 @@ Tienes disponibles tres puntos de enganche en el lado cliente para interactuar
 con el flujo de trabajo de correo electrónico. Todos ellos se invocan al
 utilizar el comando `git am`, por lo que si no utilizas dicho comando, puedes
 saltar directamente a la siguiente sección. Si recibes parches a través de
-correo-e preparados con `git format-patch`, es posible que parte de lo descrito
+correo electrónico preparados con `git format-patch`, es posible que parte de lo descrito
 en esta sección te pueda ser útil.
 
 El primer punto de enganche que se activa es `applypatch-msg`. Recibe un solo
@@ -113,10 +113,10 @@ para normalizar el mensaje permitiendo al script que lo edite sobre la marcha.
 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
+revisar la situación (snapshot) antes de confirmarla. Con este script puedes,
 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.
+cero, abortará el comando `git am` sin confirmar el parche.
 
 El último punto de enganche que se activa durante una operación `git am` es el
 punto `post-applypatch`. Puedes utilizarlo para notificar de su aplicación al
@@ -149,7 +149,7 @@ puedes autogenerar documentación, y otras cosas.
 
 El punto de enganche `post-merge` se activa tras completarse la ejecución de un
 comando `git merge`. Puedes utilizarlo para recuperar datos de tu carpeta de
-trabajo que Git no puede controlar, como por ejemplo datos relativos a
+trabajo que Git no puede controlar como, por ejemplo, datos relativos a
 permisos. Este punto de enganche puede utilizarse también para comprobar la
 presencia de ciertos archivos, externos al control de Git, que desees copiar
 cada vez que cambie la carpeta de trabajo.
@@ -158,7 +158,7 @@ El punto `pre-push` se ejecuta durante un `git push`, justo cuando las
 referencias remotas se han actualizado, pero antes de que los objetos se
 transfieran. Recibe como parámetros el nombre y la localización del remoto, y
 una lista de referencias para ser actualizadas, a través de la entrada
-estándar. Puedes utilizarlo para validar un conjunto de actualizaciones de
+estándar (`stdin`). Puedes utilizarlo para validar un conjunto de actualizaciones de
 referencias antes de que la operación de `push` tenga lugar (ya que si
 el script retorna un valor distinto de cero, se abortará la operación).
 
@@ -183,12 +183,12 @@ como desees.
 
 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,
+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á
 aceptada. Puedes utilizar este punto de enganche para realizar tareas tales
-como la de comprobar que ninguna de las referencias actualizadas no son de
+como la de comprobar que ninguna de las referencias actualizadas son de
 avance directo (non-fast-forward); o para comprobar que el usuario que realiza
-el envío tiene realmente permisos para para crear, borrar o modificar
+el envío tiene realmente permisos para crear, borrar o modificar
 cualquiera de los archivos que está tratando de cambiar.
 
 ===== `update`
@@ -197,8 +197,8 @@ El punto de enganche `update` es muy similar a `pre-receive`, pero con la
 diferencia de que se activa una vez por cada rama que se está intentando
 actualizar con el envío. Si la persona que realiza el envío intenta actualizar
 varias ramas, `pre-receive` se ejecuta una sola vez, mientras que `update` se
-ejecuta tantas veces como ramas se estén actualizando. El lugar de recibir
-datos desde la entrada estándar (stdin), este script recibe tres argumentos:
+ejecuta tantas veces como ramas se estén actualizando. En lugar de recibir
+datos desde la entrada estándar (`stdin`), este script recibe tres argumentos:
 el nombre de la rama, la clave SHA-1 a la que esta apuntada antes del envío, y
 la clave SHA-1 que el usuario está intentando enviar. Si el script `update`
 termina con un código de salida distinto de cero, únicamente los cambios de esa
@@ -209,8 +209,8 @@ rama son rechazados; el resto de ramas continuarán con sus actualizaciones.
 El punto de enganche `post-receive` se activa cuando termina todo el proceso,
 y se puede utilizar para actualizar otros servicios o para enviar
 notificaciones a otros usuarios. Recibe los mismos datos que `pre-receive`
-desde la entrada estándar. Algunos ejemplos de posibles aplicaciones pueden ser
-la de alimentar una lista de correo-e, avisar a un servidor de integración
+desde la entrada estándar (`stdin`). Algunos ejemplos de posibles aplicaciones pueden ser
+la de alimentar una lista de correo electrónico, 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