Forks-y-aportes-a-la-comunidad.md

@@ -255,7 +255,7 @@ Hasta acá consideramos el caso en que iniciamos un fork de un repo GitHub y pon
 Hay que ser cuidadosx porque eventualmente vamos a utilizar herramientas que permiten "re-escribir la historia". Observen la formulación: en todo lo que sigue, no vamos a re-escribir la historia. Lo que vamos a hacer es dejar una huella mejor ordenada de la historia. Pero vamos a guardar todo, o casi todo. Y en cada caso que se esté haciendo algo que pueda borrar información del repo lo señalaremos. ¿Ya quedó atrás el pánico?
 
 Primero un resumen de la historia: 
-- al instante de hacer el fork de un repo se lo clona en una nueva instancia eb otro namespace, con todo lo que contienen. Entonces el repo y el fork comparten los commits, ramas, tags, etc. que  existían entonces. Comparten al menos el commit inicial y la rama principal, llamémosla master aquí.
+- al instante de hacer el fork de un repo se lo clona en una nueva instancia en otro namespace, con todo lo que contienen. Entonces el repo y el fork comparten los commits, ramas, tags, etc. que  existían entonces. Comparten al menos el commit inicial y la rama principal, llamémosla master aquí.
 - los dos repos evolucionan por separado y recorren caminos o grafos diferentes
 - pero siempre siguen compartiendo ese historial inicial común, sobre el cual sólo se agregaron contribuciones diferenciales (de hecho, si hay algo que nunca hay que borrar, es la rama y el commit desde el cual se ha hecho un fork)
 
@@ -271,8 +271,19 @@ La definición más precisa de lo que hace ese .. es que muestra todos los commi
 
 Recorremos hasta el último commit del log y copiamos su hash. Si lo único que nos interesa es ir a ver ese hash, podemos resumir los reportes de log:
 ```
-git log upstream/master..HEAD --oneline
+$ git log upstream/master..HEAD --oneline
+a4fbfb1 (HEAD -> master, tag: v0.1-arrayan, origin/master, origin/HEAD) Merge branch 'master' of https://github.com/UdelaRInterior/sympa
+73fa356 Added .gitignore
+6476d90 galaxy_install_info added to .gitignore
+cc92007 Change topics.conf template
+516a05f Change role name
+6f60cd2 Correct syntax
+c1f7238 Correct syntax
+e7e4ea8 Correct syntax
+ce4a63d Work with postgreSQL and create the robots
 ```
+(los ejemplos reales de este tutorial vienen del repo `UdelaRInterior/ansible-sympa`)
+
 Nos paramos entonces en ese hash: 
 ```
 $ git checkout ce4a63d
@@ -313,7 +324,7 @@ Date:   Fri Jun 21 18:06:45 2019 +0200
 Pues es ahí que podemos crear nuestra rama `upstream-master`, y pararnos en ella:  
 ```
 $ git branch upstream-master 
-$ git checkiut upstream-master 
+$ git checkout upstream-master 
 ```
 Rama así bien injertada en el arbol del repo, de manera a que se actualice sin conflicto: 
 ```
@@ -321,11 +332,9 @@ $ git pull upstream/master
 ```
 Y ya tenemos nuestra rama upstream-master lista para preparar PRs para el repo de upstream.
 
-Hasta acá hemos resuelto el órden el el repo sin nisiquiera tener en algo que "re-escribir la historia". Simplemente la recorrimos. 
-
-Ahora, si a la hora de ordenarse para hacer PRs en upstream, nos damos cuenta que la rama `upstream-master` ya está creada, y que por alguna razón o error no sigue el mismo camino que su espejo `upstream/master` (¿notan la sutileza? `nom-bre` `remote/nombre`). 
+Hasta acá hemos resuelto el órden el el repo sin ni siquiera tener en algo que "re-escribir la historia". Simplemente la recorrimos. 
 
-Ahí sí conviene, no re-escribir la histria, sino corregir una versión mal reportada de la historia. 
+Ahora bien, si a la hora de prepararse para hacer PRs en upstream, nos damos cuenta que la rama `upstream-master` ya existe, y que por alguna razón o error no sigue el mismo camino que su espejo `upstream/master` (¿notan la sutileza? `nom-bre` `remote/nombre`), ahí sí conviene, no re-escribir la histria, sino corregir una versión mal reportada de la misma. 
 
 A lo sumo, si por alguna razón no queremos perder el historial de esa rama equivocada, bien podemos preservarla con otro nombre antes de corregirla: 
 ```
@@ -352,7 +361,7 @@ $ git pull upstream/master
 
 Documentándome un poco para escribir esto, caí sobre un billete de blog que, si sos de los que leen sólo los titulares, te hará hacer muchas cagadas: [Always Squash and Rebase your Git Commits](https://blog.carbonfive.com/2017/08/28/always-squash-and-rebase-your-git-commits/).
 
-Lo que conviene entender de ese título es que en muchos casos, es bueno poner orden a posteriori. La historia escrita en un git puede ser verborrágica. No siempre recordamos hacer `git ---amend` cuando nos olvidamos de un detalle en un commit. ¿cuántas veces hacemos un commit sólo por cambiar de rama o para retomar el trabajo en otra computadora?
+Lo que conviene entender de ese título es que en muchos casos, es bueno poner orden a posteriori. La historia escrita en un git puede ser verborrágica. No siempre recordamos hacer `git ---amend` cuando nos olvidamos de un detalle en un commit. ¿Y cuántas veces hacemos un commit sólo por cambiar de rama o para retomar el trabajo en otra computadora?
 
 Todo eso, no sólo no aporta nada y hace ruido, sino que además comprende metadatos que pueden llegar a interactuar con temas de privacidad. Es sano tirar a la basura los borradores y ordenar mejor la biblioteca.