Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Applying forgotten changes from master branch

  • Loading branch information...
commit 0e65366f2c07504ebf9226fa4398aae6402bc0b0 1 parent 42a1bd6
@t-t t-t authored
View
12 Makefile
@@ -1,6 +1,7 @@
# The language we are building.
# For example, Run "make LANG=es" to build the Spanish edition.
LANG := en
+SHELL := /bin/bash
.PHONY: target clean sync push
@@ -12,12 +13,15 @@ TXTFILES := preface.txt intro.txt basic.txt clone.txt branch.txt history.txt \
multiplayer.txt grandmaster.txt secrets.txt drawbacks.txt translate.txt
book.xml: $(addprefix $(LANG)/,$(TXTFILES))
- # Kludge to make preface sections work for languages besides English.
- echo '[specialsections]' > conf
- sed -n '/^== .* ==$$/p' $(LANG)/preface.txt | sed 's/^== \(.*\) ==$$/^\1$$=sect-preface/' >> conf
# 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.
+ if [[ `asciidoc --version | cut -f 2 -d ' '` < "8.4.5" ]]; then \
+ echo '[specialsections]' > conf ; \
+ sed -n '/^== .* ==$$/p' $(LANG)/preface.txt | sed 's/^== \(.*\) ==$$/^\1$$=sect-preface/' >> conf ; \
+ else echo "" > 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 - > $@
@@ -62,7 +66,7 @@ clean:
-rm -rf book.xml book.html book
sync: target
- rsync -r book.html book.pdf book/* blynn@tl1.stanford.edu:www/gitmagic/intl/$(LANG)/
+ rsync -r book.html book.pdf book/* blynn@xenon.stanford.edu:www/gitmagic/intl/$(LANG)/
public:
git push blynn@git.or.cz:srv/git/gitmagic.git
View
3  book.css
@@ -13,7 +13,8 @@ pre {
}
ul li p {
- margin-bottom:0;
+ margin: 0;
+ padding: 0;
}
/* Based on http://phrogz.net/CSS/columns3.html */
View
143 es/drawbacks.txt
@@ -0,0 +1,143 @@
+== Apéndice A: Defectos de Git ==
+
+Hay algunos problema con Git que barrí bajo la alfombra. Algunos pueden ser manejados con facilidad
+utilizando scripts y hooks, otros requieren reorganizar or redefinir el proyecto, y por las molestias
+que quedan, uno simplemente va a tener que esperar. ¡O mejor aún, unirse y ayudar!
+
+=== Debilidades De SHA1 ===
+
+A medida que pasa el tiempo, los criptógrafos descubren más y más debilidades de SHA1.
+Al día de hoy, encontrar colisiones en los hashes es feasible para organizaciones con buenos fondos.
+En unos años, quizás incluso una PC típica tendrá suficiente poder de cómputo para
+corromper un repositorio de Git de manera silenciosa.
+
+Esperemos que Git migre a una función de hash mejor antes de que nuevas investigaciones
+destruyan el SHA1.
+
+=== Microsoft Windows ===
+
+Git en Microsoft Windows puede ser engorroso:
+
+- http://cygwin.com/[Cygwin], un ambiente similar a Linux para Windows, contiene http://cygwin.com/packages/git/[una versión de Git para Windows].
+
+- http://code.google.com/p/msysgit/[Git en MSys] es una alternativa que requiere un soporte mínimo para la ejecución, aunqeu algunos de los comandos necesitan cierto trabajo.
+
+=== Archivos No Relacionados ===
+
+Si tu proyecto es muy grande y contiene muchos archivos no relacionados
+que están siendo cambiados de manera constante,
+Git puede estar en desventaja ante otros sistemas, porque no se monitorean
+archivos simples. Git maneja proyectos enteros, lo cual suele ser beneficioso.
+
+Una solución es partir tu proyecto en pedazos, cada uno consistiendo
+de archivos relacionados. Usa *git submodule* si quieres mantener todo en un único repositorio.
+
+=== ¿Quién Edita Qué? ===
+
+Algunos sistemas de control de versiones te fuerzan a marcar un archivo de manera explícita antes de editarlo.
+Si bien esto es especialmente molesto cuando esto involucra comunicarse con un servidor central,
+también tiene dos beneficios:
+
+ 1. Los diffs son rápidos porque solo se precisa examinar los archivos marcados.
+
+ 2. Uno puede descubrir quién más está trabajando en el archivo preguntándole al servidor central quien lo marcó para edición.
+
+Con scripts apropiados, se puede alcanzar lo mismo con Git. Esto requiere cooperación del programador, quien debería ejecutar ciertos scripts cuando edita un archivo.
+
+=== Historia Por Archivo ===
+
+Como Git guarda cambios por proyecto, reconstruir la historia de un archivo dado requiere más trabajo que en sistemas de control de versiones que administran archivos individuales.
+
+El problema suele ser leve, y vale tenerlo dado que otras operaciones son increíblemente eficientes.
+Por ejemplo, `git checkout` es más rápido que `cp -a`, y los deltas de
+un proyecto completo comprimen mejor que colecciones de deltas por archivo.
+
+=== Clonado inicial ===
+
+Cuando hay una historia larga, crear un clon es más costoso que hacer
+checkout de código en otros sistemas de control de versiones.
+
+El costo inicial lo vale a la larga, dado que la mayoría de
+las operaciones futuras van a ser rápidas y desconectado. De todos modos,
+en algunas situaciones, seria preferible crear un clon sin profundidad
+usando la opción `--depth`. Esto es mucho más rápido, pero el clon
+resultante tiene su funcionalidad reducida.
+
+=== Proyectos Volátiles ===
+
+Git fue escrito para ser rápido respecto al tamaño de los cambios. Los humanos hacen pequeñas ediciones
+de versión a versión. Un bugfix de una línea acá, una nueva funcionalidad allá,
+comentarios retocados, y así en adelante. Pero si tus archivos son radicalmente
+diferentes en revisiones sucesivas, entonces en cada commit, tu historia crece necesariamente igual que
+tu proyecto entero.
+
+No hay nada que ningún sistema de control de versiones pueda hacer sobre esto, pero los usuarios standard de Git van a sufrir más, dado que las historias son clonadas.
+
+La razón por la que los cambios son tan grandes deberían ser examinadas.
+Tal vez los formatos de los archivos deberían ser cambiados, ediciones
+pequeñas deberían causar cambios menores en a lo sumo unos pocos archivos.
+
+O tal vez una base de datos o una solución de backup/archivado es lo que realmente se necesita, no un sistema de control de versiones. Por ejemplo, un el control de versiones es poco adecuado para administrar fotos tomadas periódicamente con una webcam.
+
+
+Si los archivos deben cambiar constantemente, y realmente se necesita que estén versionados, una posibilidad es usar Git de una forma centralizada.
+Uno puede crear clones sin profundidad, lo cual acarrea poco y nada de la historia del proyecto.
+Por supuesto, muchas herramientas de git no van a estar disponibles,
+y los arreglos deben ser enviados como patches.
+Esto probablement no sea problema, dado que no está claro por qué alguien quisiera un historial de archivos salvajemente inestables.
+
+Otro ejemplo es un proyecto que depende de firmware, que toma la forma de
+un archivo binario enorme. La historia de este firmware no es de interés para los usuarios,
+y las actualizaciones comprimen de forma insatisfactoria, por lo que las revisiones
+de firmware aumentarían el tamaño del repositorio de manera innecesaria.
+
+En este caso, el código fuente debe ser guardado en un repositorio de Git,
+y el archivo binario debe ser mantenido de forma separada. Para hacer la vida
+más fácil, uno puede distribuír un script que usa Git para clonar el código y rsync
+o un clon sin profundidad de Git para el firmware.
+
+=== Contador Global ===
+
+Algunos sistemas de control de versiones centralizados, mantienen un entero positivo que aumenta cuando un nuevo commit es aceptado.
+Git se refiere a los cambios por su hash, lo que es mejor en muchas circunstancias.
+
+Pero a algunas personas les gusta tener este entero a mano. Por suerte es fácil escribir
+scripts de forma que con cada update, el repositorio central de git incrementa un entero,
+tal vez en un tag, y lo asocia con el hash del último commit.
+
+Cada clon podría mantener esete contador, pero esto sería probablemente inútil,
+dado que solo el repositorio central y su contador son los que importan.
+
+=== Subdirectorios Vacíos ===
+
+Los subdirectorios vacíos no pueden ser administrados. Crea archivos dummy para evitar este problema.
+
+La implementación actual de Git, y no su diseño, es quien tiene la culpa de este problema. Con suerte,
+una vez que Git gane más tracción, más usuarios van a clamar por
+esta funcionalidad y va a ser implementada.
+
+=== Commit Inicial ===
+
+El estereotipo de de un informático teórico cuenta desde 0, en lugar de desde 1.
+Lamentablemente, con respecto a los commit, Git no mantiene esta convención. Muchos
+comandos son poco amigables antes del commit inicial. Adicionalmente algunos casos
+borde deben ser manejados de forma especial, como hacer rebase de una rama con
+un commit inicial distinto.
+
+Git se beneficiaría al definiri el commit cero: tan pronto como se construye un
+repositorio, HEAD debería ser un string conteniendo 20 bytes de 0. Este commit especial
+representa un árbol vacío, sin padre, que en algún momento es parte de todos los repositorios de Git.
+
+Entonces el correr git log, por ejemplo, informaría al usuario que no se han hecho commits aún,
+en lugar de salir con un error fatal. Algo similar pasaría con otras herramientas.
+
+Cada commit inicial es de forma implícita un descendiente de este commit cero.
+
+Lamentablemente igual hay algunos casos que presentan problemas.
+Si varias ramas con commits iniciales diferentes se mergean juntas,
+entonces un rebase del resultado requiere una buena cantidad de intervención manual.
+
+=== Rarezas De La Interfaz ===
+
+Para los commits A y B, el significado de las expresiones "A..B" y "A...B" depende
+de si el comando espera dos puntas o un rango. Ver *git help diff* y *git help rev-parse*
View
260 es/grandmaster.txt
@@ -0,0 +1,260 @@
+== Gran Maestría en Git ==
+
+Esta página con nombre pretencioso es el cajón donde dejar los trucos de Git no categorizados.
+
+=== Lanzamientos de Código ===
+
+Para mis proyectos, Git controla únicamente los ficheros que me gustaría archivar y enviar a
+los usuarios. Para crear un tarball del código fuente, ejecuto:
+
+ $ git archive --format=tar --prefix=proj-1.2.3/ HEAD
+
+=== Commit De Lo Que Cambió ===
+
+Decirle a Git cuándo agregaste, eliminaste o renombraste archivos es complicado
+para ciertos proyectos. En cambio, puedes escribir:
+
+ $ git add .
+ $ git add -u
+
+Git va a mirar los archivos en el directorio actual y resolver los detalles
+por si mismo. En lugar del segundo comando add, corre `git commit -a` si estás en condiciones
+de hacer commit. Ver en *git help ignore* como especificar archivos
+que deberían ser ignorados.
+
+Puedes hacer lo de arriba en un único paso con:
+
+ $ git ls-files -d -m -o -z | xargs -0 git update-index --add --remove
+
+Las opciones *-z* y *-0* previenen efectos secundarios adversos de archivos que contienen
+caracteres extraños. Como este comando agrega archivos ignorados, podrías querer usar la opción
+`-x` or `-X`.
+
+=== ¡Mi Commit Es Muy Grande! ===
+
+¿Postergaste hacer un commit por demasiado tiempo? ¿Estabas enfervorizado
+escribiendo código y te olvidaste del control de fuentes hasta ahora?
+¿Hiciste una serie de cambios no relacionados, simplemente porque es tu estilo?
+
+No te preocupes, ejecuta:
+
+ $ git add -p
+
+Por cada edición que hiciset, Git va a mostrar el pedazo de código que fue cambiado,
+y preguntar si debería ser parte del próximo commit. Contesta con "y" o "n".
+Hay otras opciones, como posponer la decisión; escribe "?" para saber más.
+
+Una vez satisfecho, escribe
+
+ $ git commit
+
+para hacer un commit que solo contiene los cambios seleccionados (los cambios 'staged'). Asegúrate
+de omitir la opción *-a*, o Git va a poner todo lo editado en el commit.
+
+¿Que pasa si editaste varios archivos en varios lugares? Revisar cada cambio uno por uno
+se vuelve frustrante y adormecedor. En este caso, usa *git add -i*, cuya interfaz
+es menos clara pero más flexible. Con solo presionar un par de teclas, puedes poner
+o sacar del 'stage' varios archivos a la vez, o revisar y seleccionar cambios solamente
+en archivos particulares. Como alternativa se puede usar *git commit --interactive*, el
+cual hace commit luego de que terminas.
+
+==== Cambios en el 'stage' ====
+
+Hasta ahora hemos evitado el famoso 'indice' de git, pero ahora debermos enfrentarlo
+para explicar lo de arriba. El indice es un area temporal de montaje. Git evita enviar
+datos directamente entre tu proyecto y su historia. En su lugar, Git primero escribe datos
+al índice, y luego copia los datos del índice a su destino final.
+
+Por ejemplo, *commit -a* es en realidad un proceso de 2 pasos. El primer paso pone
+una foto del estado actual de cada archivo administrado en el índice. El segundo paso
+graba de forma permanente esa foto que está en el índice. Un commit hecho sin *-a*
+solo efectúa el segundo paso, y solo tiene sentido luego de haber ejecutado comandos
+que de alguna forma alteran el índice, como *git add*.
+
+Usualmente podemos ignorar el índice y pretender que estamos leyendo y escribiendo
+directo en la historia. En esta ocasión, queremos un control más fino de lo que se
+escribe en la historia, y nos vemos forzados a manipular el índice. Guardamos una foto de
+algunos, pero no todos, de nuestros cambios en el índice, y luego grabamos
+de forma permanenta esta instantánea cuidadosamente organizada.
+
+=== No Pierdas La Cabeza ===
+
+El tag HEAD (Cabeza) es como un cursor que normalmente apunta al último commit, avanzando
+con cada nuevo commit. Algunos comandos de Git te dejan moverlo. Por ejemplo:
+
+ $ git reset HEAD~3
+
+mueve el HEAD tres commits hacia atrás. Por lo tanto todos los comandos de Git ahora
+actúan como si no hubieras hecho esos últimos tres commits, mientras tus archivos
+permanecen en el presente. Ver la página de ayuda para algunas aplicaciones.
+
+¿Como hago para volver al futuro? Los commits del pasado nada saben del futuro.
+
+Teniendo el SHA1 del HEAD original, hacemos:
+
+ $ git reset SHA1
+
+Pero supongamos que nunca lo anotaste. No te preocupes, para comandos como este, Git
+guarda el HEAD original como un tag llamado ORIG_HEAD, y puedes volver sano y salvo con:
+
+ $ git reset ORIG_HEAD
+
+=== Cazando Cabezas ===
+
+Quizás ORIG_HEAD no es suficiente. Quizás acabas de descubrir que cometiste un error monumental
+y que hay que volver a un commit antiguo en una rama olvidada hace largo tiempo.
+
+Por defecto, Git guarda un commit por al menos 2 semanas, incluso si le ordenaste destruir
+la rama que lo contenía. El problema es encontra el hash apropiado. Podrías
+mirar todos los hashes en `.git/objects` y usar prueba y error para encontrar el que buscas.
+Pero hay una forma mucho más fácil.
+
+Git guarda el hash de cada commit que hace en `.git/logs`. El subdirectorio `refs` contiene
+la historia de la actividad en todas las ramas, mientras que el archivo `HEAD` tiene cada hash
+que alguna vez ha tomado. Este último puede usarse para encontrar hashes de commits en branches
+que se han borrado de manera accidental.
+
+El comando reflog provee una interfaz amigable para estos logs. Prueba
+
+ $ git reflog
+
+En lugar de cortar y pegar hashes del reflog, intenta:
+
+ $ git checkout "@{10 minutes ago}"
+
+O prueba un checkout del 5to commit que visitaste hacia atrás:
+
+ $ git checkout "@{5}"
+
+Ver la sección ``Specifying Revisions'' de *git help rev-parse* por mas datos.
+
+Podrías querer configurar un periodo de gracia mayor para los commits condenados. Por ejemplo:
+
+ $ git config gc.pruneexpire "30 days"
+
+significa que un commmit eliminado se va a perder de forma permanente solo cuando
+hayan pasado 30 dáis y se ejecute *git gc*.
+
+También podrías querer deshabilitar invocaciones automáticas de *git gc*:
+
+ $ git config gc.auto 0
+
+en cuyo caso los commits solo serán borrados cuando ejecutes *git gc* de forma manual.
+
+=== Construyendo sobre Git ===
+
+Siguiendo la tradición UNIX, el diseño de Git permite ser facilmente usado como un componente de bajo
+nivel de otros programas, como GUI e interfaces web, interfaces de linea de comandos alternativas,
+herramientas de manejo de patches, herramientas de importación y conversión, etc.
+De hecho, algunos de los comandos de Git son ellos mismos scripts parados sobre los hombros de gigantes.
+Con unos pocos ajustes, puedes personalizar Git para cubrir tus necesidades.
+
+Un truco simple es usar los alias incluidos en git para acortar los comandos
+usados de forma más frecuente:
+
+ $ git config --global alias.co checkout
+ $ git config --global --get-regexp alias # muestra los alias actuales
+ alias.co checkout
+ $ git co foo # igual a 'git checkout foo'
+
+Otro es imprimir la rama actual en el prompt, o en el título de la ventana.
+
+Usar
+
+ $ git symbolic-ref HEAD
+
+muestra el nombre de la rama actual. En la práctica, es probable que quieras quitar el
+"refs/heads/" e ignorar los errores:
+
+ $ git symbolic-ref HEAD 2> /dev/null | cut -b 12-
+
+El subdirectorio +contrib+ es la cueva de los tesoros de las herramientas hechas con Git.
+Con tiempo, algunas de ellas pueden ser promovidas a comandos oficiales. En Debian y Ubuntu,
+este directorio está en +/usr/share/doc/git-core/contrib+.
+
+Un residente popular es +workdir/git-new-workdir+. Usando symlinks inteligentes, este script
+crea un nuevo directorio de trabajo cuya historia es compartida con el repositorio original:
+ $ git-new-workdir repositorio/existente nuevo/directorio
+
+El nuevo directorio y sus archivos interiores pueden ser vistos como un clon, excepto que como la
+historia es compartida, ambos árboles se mantienen sincronizados de forma automática.
+No hay necesidad de merges, push ni pull.
+
+=== Acrobacias Peligrosas ===
+
+En estos dias, Git hace difícil que el usuario destruya datos de manera accidental.
+Pero si sabes lo que estás haciendo, puedes hacer caso omiso de las trabas de seguridad para
+los comandos comunes.
+
+
+*Checkout*: Los cambios no commiteados hacen que checkout falle. Para destruir tus cambios, y hacer checkout de un commit dado, usa la opción de forzar:
+
+ $ git checkout -f COMMIT
+
+Por otro lado, si especificas una ruta específica para hacer checkout, no hay chequeos de seguridad.
+Las rutas suministradas son sobre-escritas de forma silenciosa.
+Hay que tener cuidado al usar checkout de esta forma:
+
+*Reset*: Reset también falla en presencia de cambios sin commmitear. Para hacerlo a la fuerza, ejecuta:
+
+ $ git reset --hard [COMMIT]
+
+*Branch*: El borrado de una rama falla si esto causa que se pierdan cambios, para forzarlo escribe:
+
+ $ git branch -D BRANCH # en lugar de -d
+
+De forma similar, intentar sobreescribir una rama moviendo otra, falla si esto resultase en pérdida de datos. Para forzar el mover una rama, corre:
+
+ $ git branch -M [ORIGEN] DESTINO # en lugar de -m
+A diferencia de checkout y reset, estos dos comandos evitan la destrucción de datos.
+Los cambios están aún guardados en el subdirectorio .git, y pueden obtenerse
+recuperando el has apropiado de `.git/logs` (ver "Cazando Cabezas" arriba).
+Por defecto, serán guardados por al menos dos semanas.
+
+*Clean*: Algunos comandos de Git se rehúsan a proceder porque están preocupados
+de destruir archivos no monitoreados. Si tienes la certeza de que todos los archivos
+y directorios sin monitorear son prescindibles, se pueden borrar sin piedad con:
+
+ $ git clean -f -d
+
+¡La próxima vez, ese comando molesto va a funcionar!
+
+=== Mejora Tu Imagen Pública ===
+
+Los errores estúpidos abundan en la historia de muchos proyectos. El más
+preocupante son los archivos perdidos por el olvido de ejecutar *git add*.
+Por suerte nunca perdí datos cruciales por omisión accidental, dado que muy rara
+vez elimino directorios de trabajo originales. Lo normal es que note el error un par
+de commits mas adelante, por lo que el único daño es un poco de historia perdida
+y el tener que admitir la culpa.
+
+También me preocupo por no tenes espacios en blanco al final de las líneas.
+Aunque son inofensivos, procuro que nunca aparezcan en la historia pública.
+
+Además, si bien nunca me sucedió, me preocupo por no dejar conflictos de merge
+sin resolver. Usualmente los descubro al compilar el proyecto, pero hay algunos
+casos en los que se puede no notar.
+
+Es útil comprar un seguro contra la idiotez, usando un _hook_ para alertarme de
+estos problemas:
+
+ $ cd .git/hooks
+ $ cp pre-commit.sample pre-commit # En versiones mas viejas de Git: chmod +x pre-commit
+
+Ahora Git aborta un commit si se detectan espacios inútiles en blanco o conflictos
+de merge sin resolver.
+
+Para esta guía, eventualmente agregué lo siguiente al inicio del hook *pre-commit*,
+pare prevenirme de la desatención.
+
+ if git ls-files -o | grep '\.txt$'; then
+ echo FALLA! Archivos .txt sin monitorear.
+ exit 1
+ fi
+
+Varias operaciones de git soportan hooks; ver *git help hooks*. Se pueden escribir
+hooks para quejarse de errores ortográficos en los mensajes de commit, agregar nuevos archivos,
+indentar párrafos, agregar una entrada en una página, reproducir un sonido, etc.
+
+Habíamos encontrado el hook *post-update* antes, cuando discutíamos como usar Git sobre HTTP.
+Este hook actualiza algunos archivos que Git necesita para comunicación no nativa.
View
250 es/history.txt
@@ -0,0 +1,250 @@
+== Lecciones de Historia ==
+
+Una consecuencia de la naturaleza distribuída de git, es que la historia puede ser editada
+facilmente. Pero si manipulas el pasado, ten cuidado: solo reescribe la parte de
+la historia que solamente tú posees. Así como las naciones discuten eternamente sobre quién
+cometió qué atrocidad, si otra persona tiene un clon cuya versión de la historia
+difiere de la tuya, vas a tener problemas para reconciliar ambos árboles cuando éstos interactúen.
+
+Por supuesto, si también controlas todos los demás árboles, puedes simplemente
+sobreescribirlos.
+
+Algunos desarrolladores están convencidos de que la historia debería ser inmutable, incluso con sus defectos.
+Otros sienten que los árboles deberían estar presentables antes de ser mostrados en
+público. Git satisface ambos puntos de vista. Al igual que el clonar, hacer branches y hacer merges,
+reescribir la historia es simplemente otro poder que Git te da. Está en tus manos
+usarlo con sabiduría.
+
+=== Me corrijo ===
+
+¿Hiciste un commit, pero preferirías haber escrito un mensaje diferente? Entonces escribe:
+
+ $ git commit --amend
+
+para cambiar el último mensaje. ¿Te olvidaste de agregar un archivo? Ejecuta *git add* para
+agregarlo, y luego corre el comando de arriba.
+
+¿Quieres incluir algunas ediciones mas en ese último commit? Edita y luego escribe:
+
+ $ git commit --amend -a
+
+=== ... Y Algo Más ===
+
+Supongamos que el problema anterior es diez veces peor. Luego de una larga sesión hiciste unos cuantos commits.
+Pero no estás conforme con la forma en que están organizados, y a algunos de los mensajes de esos commits les
+vendría bien una reescritura. Entonces escribe:
+
+ $ git rebase -i HEAD~10
+
+y los últimos 10 commits van a aparecer en tu $EDITOR favorito. Un fragmento de muestra:
+
+ pick 5c6eb73 Added repo.or.cz link
+ pick a311a64 Reordered analogies in "Work How You Want"
+ pick 100834f Added push target to Makefile
+
+Entonces:
+
+- Elimina commits borrando líneas.
+- Reordena commits reordenando líneas.
+- Reemplaza "pick" por "edit" para marcar un commit para arreglarlo.
+- Reemplaza "pick" por "squash" para unir un commit con el anterior.
+
+Si marcaste un commit para edición, entonces ejecuta:
+
+ $ git commit --amend
+
+En caso contrario, corre:
+
+ $ git rebase --continue
+
+Por lo tanto, es bueno hacer commits temprano y seguido: siempre se puede acomodar después usando rebase.
+
+=== 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
+cuantas veces antes de estar listo para hacer push hacia el árbol central.
+
+El problema es que ahora la historia en tu clon local de Git, es un entrevero de tus cambios
+y los cambios oficiales. Preferirías ver todos tus cambios en una sección contigua,
+luego de todos los cambios oficiales.
+
+Lo descrito arriba es un trabajo para *git rebase*. En muchos casos se puede usar
+la bandera *--onto* y evitar la interacción.
+
+Ver *git help rebase* para ejemplos detallados de este asombroso comando.
+Se pueden partir commits. Incluso se pueden reordenar las branches de un árbol.
+
+=== Reescribiendo la Historia ===
+
+Ocasionalmente, se necesita algo equivalente a borrar gente de fotos oficiales,
+pero para control de código, para borrar cosas de la historia de manera Stalinesca. Por
+ejemplo, supongamos que queremos lanzar un proyecto, pero involucra un archivo que
+debería ser privado por alguna razón. Quizás dejé mi número de tarjeta de crédito en
+un archivo de texto y accidentalmente lo agregué al proyecto. Borrar el archivo es
+insuficiente, dado que se puede acceder a él en commits viejos. Debemos eliminar
+el archivo de todos los commits:
+
+ $ git filter-branch --tree-filter 'rm archivo/secreto' HEAD
+
+Ver *git help filter-branch*, donde se discute este ejemplo y se da un método
+más rápido. En general, *filter-branch* permite alterar grandes secciones de
+la historia con un solo comando.
+
+Luego, el directorio +.git/refs/original+ describe el estado de las cosas antes de la operación.
+Revisa que el comando filter-branch hizo lo que querías, y luego borra este directorio si deseas
+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===
+
+[[makinghistory]]
+¿Quieres migrar un proyecto a Git? Si está siendo administrado con alguno de los sistemas más conocidos,
+hay grandes posibilidades de que alguien haya escrito un script para exportar la historia completa a Git.
+
+Si no lo hay, revisa *git fast-import*, que lee una entrada de texto en un formato
+específico para crear una historia de Git desde la nada. Típicamente un script que usa
+este comando se acomoda de apuro y se corre una sola vez, migrando el proyecto de
+un solo tiro.
+
+Como ejemplo, pega el texto a continuación en un archivo temporal, como ser `/tmp/history`:
+----------------------------------
+commit refs/heads/master
+committer Alice <alice@example.com> Thu, 01 Jan 1970 00:00:00 +0000
+data <<EOT
+Initial commit.
+EOT
+
+M 100644 inline hello.c
+data <<EOT
+#include <stdio.h>
+
+int main() {
+ printf("Hello, world!\n");
+ return 0;
+}
+EOT
+
+
+commit refs/heads/master
+committer Bob <bob@example.com> Tue, 14 Mar 2000 01:59:26 -0800
+data <<EOT
+Replace printf() with write().
+EOT
+
+M 100644 inline hello.c
+data <<EOT
+#include <unistd.h>
+
+int main() {
+ write(1, "Hello, world!\n", 14);
+ return 0;
+}
+EOT
+
+----------------------------------
+
+Luego crea un repositorio Git desde este archivo temporal escribiendo:
+
+ $ mkdir project; cd project; git init
+ $ git fast-import < /tmp/history
+
+Puedes hacer checkout de la última versión del proyecto con:
+
+ $ git checkout master .
+
+El comando *git fast-export* convierte cualquier repositorio de git al
+formato de *git fast-import*, y puedes estudiar su salida para escribir exportadores,
+y también para transportar repositorios de git en un formato legible por humanos. De hecho
+estos comandos pueden enviar repositorios de archivos de texto sobre canales de solo texto.
+
+=== ¿Dónde Nos Equivocamos? ===
+
+Acabas de descubrir una prestación rota en tu programa, y estás seguro
+que hace unos pocos meses funcionaba. ¡Argh! ¿De donde salió este bug?
+Si solo hubieras ido testeando a medida que desarrollabas.
+
+Es demasiado tarde para eso ahora. De todos modos, dado que haz ido haciendo commits seguido, Git
+puede señalar la ubicación del problema.
+
+ $ git bisect start
+ $ git bisect bad SHA1_DE_LA_VERSION_MALA
+ $ git bisect good SHA1_DE_LA_VERSION_BUENA
+
+Git hace checkout de un estado a mitad de camino. Prueba la funcionalidad, y si aún está rota:
+
+ $ git bisect bad
+
+Si no lo está, reemplaza "bad" por "good". Git una vez más te transporta a un estado en mitad de camino
+de las versiones buena y mala, acortando las posibilidades.
+Luego de algunas iteraciones, esta búsqueda binaria va a llevarte al commit que
+causó el problema. Una vez que hayas terminado tu investigación, vuelve a tu estado
+original escribiendo:
+
+ $ git bisect reset
+
+En lugar de testear cada cambio a mano, automatiza la búsquea escribiendo:
+
+ $ git bisect run COMANDO
+
+Git utiliza el valor de retorno del comando dado, típicamente un script hecho solo para eso, para
+decidir si un cambio es bueno o malo: el comando debería salir con código 0
+si es bueno, 125 si el cambio se debería saltear, y cualquier cosa entre 1
+y 127 si es malo. Un valor negativo aborta el bisect.
+
+Puedes hacer mucho más: la página de ayuda explica como visualizar bisects, examinar
+o reproducir el log de un bisect, y eliminar cambios inocentes conocidos para que
+la búsqueda sea más rápida.
+
+=== ¿Quién Se Equivocó? ===
+
+Como muchos otros sistemas de control de versiones, Git tiene un comando blame:
+
+ $ git blame ARCHIVO
+
+que anota cada línea en el archivo dado mostrando quién fue el último en cambiarlo y cuando.
+A diferencia de muchos otros sistemas de control de versiones, esta operación trabaja desconectada,
+leyendo solo del disco local.
+
+=== Experiencia Personal ===
+
+En un sistema de control de versiones centralizado, la modificación de la historia es una operación
+dificultosa, y solo disponible para administradores. Clonar, hacer branches y merges,
+es imposible sin comunicación de red. Lo mismo para operaciones básicas como
+explorar la historia, o hacer commit de un cambio. En algunos sistemas, los usuarios
+requieren conectividad de red solo para ver sus propios cambios o abrir un archivo
+para edición.
+
+Los sistemas centralizados no permiten trabajar desconectado, y necesitan una
+infraestructura de red más cara, especialmente a medida que aumenta el número de desarrolladores. Lo
+más importante, todas las operaciones son más lentas de alguna forma, usualmente al punto
+donde los usuarios evitan comandos avanzados a menos que sean absolutamente necesarios. En casos
+extremos esto se da incluso para los comandos más básicos. Cuando los usuarios
+deben correr comandos lentos, la productividad sufre por culpa de un flujo de trabajo interrumpido.
+
+Yo experimenté estos fenómenos de primera mano. Git fue el primer sistema de control
+de versiones que usé. Me acostumbré rápidamente a él, dando por ciertas varias
+funcionalidades. Simplemente asumí que otros sistemas eran similares: elegir
+un sistema de control de versiones no debería ser diferente de elegir un editor de texto
+o navegador web.
+
+Cuando me vi obligado a usar un sistema centralizado me sorprendí. Una mala conexión
+a internet importa poco con Git, pero hace el desarrollo insoportable cuando se necesita
+que sea confiable como un disco local. Adicionalmente me encontré condicionado
+a evitar ciertos comandos por las latencias involucradas, lo que terminó
+evitando que pudiera seguir mi flujo de trabajo deseado.
+
+Cuando tenía que correr un comando lento, la interrupción de mi tren de pensamiento
+generaba una cantidad de daño desproporcionada. Mientras esperaba que se complete
+la comunicación con el servidor, hacía alguna otra cosa para pasar el tiempo, como
+revisar el e-mail o escribir documentación. A la hora de volver a la tarea original,
+el comando había terminado hace tiempo, y yo perdía más tiempo intentando recordar
+qué era lo que estaba haciendo. Los humanos no son buenos para el cambio de contexto.
+
+También había un interesante efecto tragediad-de-los-comunes: anticipando
+la congestión de la red, la gente consume más ancho de banda que el necesario
+en varias operaciones, intentando anticipar futuras demoras. El esfuerzo combinado
+intensifica la congestión, alentando a las personas a consumir aún más ancho de banda
+la próxima vez para evitar demoras incluso más largas.
View
8 es/spanish.txt
@@ -4,7 +4,9 @@ intro.txt 09751f37469d32da649b1c64862023820e0d0499
basic.txt 09751f37469d32da649b1c64862023820e0d0499
clone.txt 46c05532226868b8b3b121d9320c0150491fd181
branch.txt 46c05532226868b8b3b121d9320c0150491fd181
-history.txt
-grandmaster.txt
+multiplayer.txt
+history.txt b17fbe91cafc00866c8c82d705920cd6c5a476d3
+grandmaster.txt b17fbe91cafc00866c8c82d705920cd6c5a476d3
secrets.txt
-drawbacks.txt
+drawbacks.txt b17fbe91cafc00866c8c82d705920cd6c5a476d3
+translate.txt
Please sign in to comment.
Something went wrong with that request. Please try again.