From 554401f076c49df3d3d756f70ca20e02d848ca05 Mon Sep 17 00:00:00 2001 From: GWC Date: Sat, 14 Sep 2019 15:04:27 -0300 Subject: [PATCH] Some minors changes in section '08-customizing-git' --- .../sections/attributes.asc | 17 ++++--- book/08-customizing-git/sections/config.asc | 18 +++---- book/08-customizing-git/sections/hooks.asc | 30 ++++++------ book/08-customizing-git/sections/policy.asc | 48 +++++++++---------- 4 files changed, 56 insertions(+), 57 deletions(-) diff --git a/book/08-customizing-git/sections/attributes.asc b/book/08-customizing-git/sections/attributes.asc index fc0a4ea2..1c83bb2f 100755 --- a/book/08-customizing-git/sections/attributes.asc +++ b/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. - diff --git a/book/08-customizing-git/sections/config.asc b/book/08-customizing-git/sections/config.asc index d5eb96f5..abaac225 100755 --- a/book/08-customizing-git/sections/config.asc +++ b/book/08-customizing-git/sections/config.asc @@ -5,7 +5,7 @@ Como se ha visto brevemente en <>, 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 ===== `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 <>. @@ -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 diff --git a/book/08-customizing-git/sections/hooks.asc b/book/08-customizing-git/sections/hooks.asc index 98a51b16..975f0968 100755 --- a/book/08-customizing-git/sections/hooks.asc +++ b/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 <>. ==== @@ -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 diff --git a/book/08-customizing-git/sections/policy.asc b/book/08-customizing-git/sections/policy.asc index a68ca495..65e57a12 100644 --- a/book/08-customizing-git/sections/policy.asc +++ b/book/08-customizing-git/sections/policy.asc @@ -5,14 +5,14 @@ En esta sección, utilizarás lo aprendido para establecer un flujo de trabajo en Git que: compruebe si los mensajes de confirmación de cambios encajan en un determinado formato, obligue a realizar solo envíos de avance directo, y -permita solo a ciertos usuarios modificar ciertas carpetas del proyecto. Para +permita sólo a ciertos usuarios modificar ciertas carpetas del proyecto. Para ello, has de preparar los correspondientes scripts de cliente (para ayudar a los desarrolladores a saber de antemano si sus envíos van a ser rechazados o no), y los correspondientes scripts de servidor (para obligar a cumplir esas políticas). -He usado Ruby para escribir los ejemplos, tanto porque es mi lenguaje preferido -de scripting y porque creo que es el más parecido a pseudocódigo; de tal forma +Hemos usado Ruby para escribir los ejemplos, tanto porque es nuestro lenguaje preferido +de scripting como porque creemos que es el más parecido a pseudocódigo; de tal forma que puedas ser capaz de seguir el código, incluso si no conoces Ruby. Pero, puede ser igualmente válido cualquier otro lenguaje. Todos los script de ejemplo que vienen de serie con Git están escritos en Perl o en Bash shell, por @@ -28,7 +28,7 @@ y tiene tres argumentos: * La vieja revisión de la rama que se está modificando * La nueva revisión que se está subiendo a la rama -También puedes tener acceso al usuario que está enviando, si este los envía a +También puedes tener acceso al usuario que los está enviando, si este los envía a través de SSH. Si has permitido a cualquiera conectarse con un mismo usuario (como "git", por ejemplo), has tenido que dar a dicho usuario una envoltura (shell wraper) que te permite determinar cuál es el usuario que se conecta @@ -51,7 +51,7 @@ puts "Enforcing Policies..." puts "(#{$refname}) (#{$oldrev[0,6]}) (#{$newrev[0,6]})" ---- -Sí, estoy usando variables globales. No me juzgues por ello, que es más +Sí, estamos usando variables globales. No nos juzguen por ello, que es más sencillo mostrarlo de esta manera. [[r_enforcing_commit_message_format]] @@ -67,9 +67,9 @@ y, si no lo trae, salir con un código distinto de cero, de tal forma que el envío (push) sea rechazado. Puedes obtener la lista de las claves SHA-1 de todos las confirmaciones de -cambios enviadas cogiendo los valores de `$newrev` y de `$oldrev`, y pasándolos -a comando de mantenimiento de Git llamado `git rev-list`. Este comando es -básicamente el mismo que `git log`, pero por defecto, imprime solo los +cambios enviadas recogiendo los valores de `$newrev` y de `$oldrev`, y pasándolos +al comando de mantenimiento de Git llamado `git rev-list`. Este comando es +básicamente el mismo que `git log`, pero por defecto, imprime sólo los valores SHA-1 y nada más. Con él, puedes obtener la lista de todas las claves SHA que se han introducido entre una clave SHA y otra clave SHA dadas; obtendrás algo así como esto: @@ -84,8 +84,8 @@ dfa04c9ef3d5197182f13fb5b9b1fb7717d2222a 17716ec0f1ff5c77eff40b7fe912f9f6cfd0e475 ---- -Puedes coger esta salida, establecer un bucle para recorrer cada una de esas -confirmaciones de cambios, coger el mensaje de cada una y comprobarlo contra +Puedes recoger esta salida, establecer un bucle para recorrer cada una de esas +confirmaciones de cambios, recoger el mensaje de cada una y comprobarlo contra una expresión regular de búsqueda del patrón deseado. Tienes que imaginarte cómo puedes obtener el mensaje de cada una de esas @@ -107,7 +107,7 @@ changed the version number ---- Una vía sencilla para obtener el mensaje, es la de ir hasta la primera línea -en blanco y luego coger todo lo que siga a esta. En los sistemas Unix, lo +en blanco y luego tomar todo lo que siga a ésta. En los sistemas Unix, lo puedes realizar con el comando `sed`: [source,console] @@ -116,7 +116,7 @@ $ git cat-file commit ca82a6 | sed '1,/^$/d' changed the version number ---- -Puedes usar este "truco de magia" para coger el mensaje de cada confirmación +Puedes usar este "truco de magia" para recoger el mensaje de cada confirmación de cambios que se está enviando y salir si localizas algo que no cuadra en alguno de ellos. Para salir del script y rechazar el envío, recuerda que debes salir con un código distinto de cero. El método completo será algo así como: @@ -159,7 +159,7 @@ El primer paso es escribir tu lista de control de accesos (ACL). Su formato es muy parecido al del mecanismo ACL de CVS: utiliza una serie de líneas donde el primer campo es `avail` o `unavail` (permitido o no permitido), el segundo campo es una lista de usuarios separados por comas, y el último campo es la -ubicación (path) sobre el que aplicar la regla (dejarlo en blanco equivale a un +ubicación (path) sobre la que aplicar la regla (dejarlo en blanco equivale a un acceso abierto). Cada uno de esos campos se separan entre sí con el carácter barra vertical ('|'). @@ -266,9 +266,9 @@ end check_directory_perms ---- -Se puede obtener una lista de los nuevos commits a enviar con `git rev-list`. +Se puede obtener una lista de los nuevos 'commits' a enviar con `git rev-list`. Para cada uno de ellos, puedes ver qué archivos se quieren modificar y -asegurarse que el usuario que está enviando los archivos tiene acceso a todos +asegurarte que el usuario que está enviando los archivos tiene acceso a todos ellos. Desde este momento, los usuarios ya no podrán subir cambios con mensajes de @@ -278,7 +278,7 @@ los que no tienen acceso. ===== Comprobación Si lanzas `chmod u+x .git/hooks/update`, siendo este el archivo en el que hemos -introducido el código anterior, y probamos a subir un commit con un mensaje que +introducido el código anterior, y probamos a subir un `commit` con un mensaje que no cumple las reglas, verás algo como esto: [source,console] @@ -332,7 +332,7 @@ error: failed to push some refs to 'git@gitserver:project.git' ---- Verás un mensaje de rechazo remoto para cada referencia que tu script ha -rechazado, y te dice qué fue rechazado explícitamente debido al fallo del +rechazado, y te dice que fue rechazado explícitamente debido al fallo del script de enganche. Y más aún, si alguien intenta realizar un envío, en el que haya confirmaciones @@ -345,7 +345,7 @@ carpeta `lib`, verá esto: [POLICY] You do not have access to push to lib/test.rb ---- -Y eso es todo. De ahora en adelante, en tanto en cuando el script `update` esté +Y eso es todo. De ahora en adelante, en tanto el script `update` esté presente y sea ejecutable, tu repositorio nunca se verá perjudicado, nunca tendrá un mensaje de confirmación de cambios sin tu plantilla y tus usuarios estarán controlados. @@ -412,7 +412,7 @@ $ git commit -am 'test [ref: 132]' 1 file changed, 1 insertions(+), 0 deletions(-) ---- -A continuación, se necesita también asegurarse de no estar modificando +A continuación,los usuarios necesitan también asegurarse de no estar modificando archivos fuera del alcance de tus permisos. Si la carpeta `.git` de tu proyecto contiene una copia del archivo de control de accesos (ACL) utilizada previamente, este script `pre-commit` podrá comprobar los límites: @@ -468,7 +468,7 @@ access = get_acl_access_data('.git/acl') La segunda diferencia es la forma de listar los archivos modificados. Debido a que el método del lado servidor utiliza el registro de confirmaciones de -cambio, pero, sin embargo, aquí la confirmación no se ha registrado aún, la +cambio, pero aquí sin embargo, la confirmación no se ha registrado aún, la lista de archivos se ha de obtener desde el área de preparación (staging area). En lugar de: @@ -498,10 +498,10 @@ estar tratando de enviar una rama local distinta sobre la misma rama remota. De todas formas, el único aspecto accidental que puede interesante capturar son los intentos de reorganizar confirmaciones de cambios ya enviadas. El -servidor te avisará de que no puedes enviar ningún no-avance-rapido, y el -enganche te impedirá cualquier envío forzado +servidor te avisará de que no puedes enviar ningún 'no-avance-rapido', y el +enganche te impedirá cualquier envío forzado. -Este es un ejemplo de script previo a reorganización que lo puede comprobar. +Este es un ejemplo de script previo a la reorganización que lo puede comprobar. Con la lista de confirmaciones de cambio que estás a punto de reescribir, las comprueba por si alguna de ellas existe en alguna de tus referencias remotas. Si encuentra alguna, aborta la reorganización: @@ -545,7 +545,7 @@ la última en la parte remota, pero que no se pueda alcanzar desde ninguno de los padres de cualquiera de las claves SHA que estás intentando enviar. Es decir, confirmaciones de avance-rápido. -La mayor pega de este sistema es el que puede llegar a ser muy lento; y muchas +La mayor desventaja de este sistema es que puede llegar a ser muy lento; y muchas veces es innecesario, ya que el propio servidor te va a avisar y te impedirá el envío, siempre y cuando no intentes forzar dicho envío con la opción '-f'. De todas formas, es un ejercicio interesante. Y, en teoría al menos, pude