es/drawbacks.txt

   1 == Apéndice A: Defectos de Git ==
   2
   3 Hay algunos problema con Git que barrí bajo la alfombra. Algunos pueden ser manejados con facilidad
   4 utilizando scripts y hooks, otros requieren reorganizar or redefinir el proyecto, y por las molestias
   5 que quedan, uno simplemente va a tener que esperar. ¡O mejor aún, unirse y ayudar!
   6
   7 === Debilidades De SHA1 ===
   8
   9 A medida que pasa el tiempo, los criptógrafos descubren más y más debilidades de SHA1.
  10 Al día de hoy, encontrar colisiones en los hashes es feasible para organizaciones con buenos fondos.
  11 En unos años, quizás incluso una PC típica tendrá suficiente poder de cómputo para
  12 corromper un repositorio de Git de manera silenciosa.
  13
  14 Esperemos que Git migre a una función de hash mejor antes de que nuevas investigaciones
  15 destruyan el SHA1.
  16
  17 === Microsoft Windows ===
  18
  19 Git en Microsoft Windows puede ser engorroso:
  20
  21 - http://cygwin.com/[Cygwin], un ambiente similar a Linux para Windows, contiene http://cygwin.com/packages/git/[una versión de Git para Windows].
  22
  23 - 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.
  24
  25 === Archivos No Relacionados ===
  26
  27 Si tu proyecto es muy grande y contiene muchos archivos no relacionados
  28 que están siendo cambiados de manera constante,
  29 Git puede estar en desventaja ante otros sistemas, porque no se monitorean
  30 archivos simples. Git maneja proyectos enteros, lo cual suele ser beneficioso.
  31
  32 Una solución es partir tu proyecto en pedazos, cada uno consistiendo
  33 de archivos relacionados. Usa *git submodule* si quieres mantener todo en un único repositorio.
  34
  35 === ¿Quién Edita Qué? ===
  36
  37 Algunos sistemas de control de versiones te fuerzan a marcar un archivo de manera explícita antes de editarlo.
  38 Si bien esto es especialmente molesto cuando esto involucra comunicarse con un servidor central,
  39 también tiene dos beneficios:
  40
  41   1. Los diffs son rápidos porque solo se precisa examinar los archivos marcados.
  42
  43   2. Uno puede descubrir quién más está trabajando en el archivo preguntándole al servidor central quien lo marcó para edición.
  44
  45 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.
  46
  47 === Historia Por Archivo ===
  48
  49 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.
  50
  51 El problema suele ser leve, y vale tenerlo dado que otras operaciones son increíblemente eficientes.
  52 Por ejemplo, `git checkout` es más rápido que `cp -a`, y los deltas de
  53 un proyecto completo comprimen mejor que colecciones de deltas por archivo.
  54
  55 === Clonado inicial ===
  56
  57 Cuando hay una historia larga, crear un clon es más costoso que hacer
  58 checkout de código en otros sistemas de control de versiones.
  59
  60 El costo inicial lo vale a la larga, dado que la mayoría de
  61 las operaciones futuras van a ser rápidas y desconectado. De todos modos,
  62 en algunas situaciones, seria preferible crear un clon sin profundidad
  63 usando la opción `--depth`. Esto es mucho más rápido, pero el clon
  64 resultante tiene su funcionalidad reducida.
  65
  66 === Proyectos Volátiles ===
  67
  68 Git fue escrito para ser rápido respecto al tamaño de los cambios. Los humanos hacen pequeñas ediciones
  69 de versión a versión. Un bugfix de una línea acá, una nueva funcionalidad allá,
  70 comentarios retocados, y así en adelante. Pero si tus archivos son radicalmente
  71 diferentes en revisiones sucesivas, entonces en cada commit, tu historia crece necesariamente igual que
  72 tu proyecto entero.
  73
  74 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.
  75
  76 La razón por la que los cambios son tan grandes deberían ser examinadas.
  77 Tal vez los formatos de los archivos deberían ser cambiados, ediciones
  78 pequeñas deberían causar cambios menores en a lo sumo unos pocos archivos.
  79
  80 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.
  81
  82
  83 Si los archivos deben cambiar constantemente, y realmente se necesita que estén versionados, una posibilidad es usar Git de una forma centralizada.
  84 Uno puede crear clones sin profundidad, lo cual acarrea poco y nada de la historia del proyecto.
  85 Por supuesto, muchas herramientas de git no van a estar disponibles,
  86 y los arreglos deben ser enviados como patches.
  87 Esto probablement no sea problema, dado que no está claro por qué alguien quisiera un historial de archivos salvajemente inestables.
  88
  89 Otro ejemplo es un proyecto que depende de firmware, que toma la forma de
  90 un archivo binario enorme. La historia de este firmware no es de interés para los usuarios,
  91 y las actualizaciones comprimen de forma insatisfactoria, por lo que las revisiones
  92 de firmware aumentarían el tamaño del repositorio de manera innecesaria.
  93
  94 En este caso, el código fuente debe ser guardado en un repositorio de Git,
  95 y el archivo binario debe ser mantenido de forma separada. Para hacer la vida
  96 más fácil, uno puede distribuír un script que usa Git para clonar el código y rsync
  97 o un clon sin profundidad de Git para el firmware.
  98
  99 === Contador Global ===
 100
 101 Algunos sistemas de control de versiones centralizados, mantienen un entero positivo que aumenta cuando un nuevo commit es aceptado.
 102 Git se refiere a los cambios por su hash, lo que es mejor en muchas circunstancias.
 103
 104 Pero a algunas personas les gusta tener este entero a mano. Por suerte es fácil escribir
 105 scripts de forma que con cada update, el repositorio central de git incrementa un entero,
 106 tal vez en un tag, y lo asocia con el hash del último commit.
 107
 108 Cada clon podría mantener esete contador, pero esto sería probablemente inútil,
 109 dado que solo el repositorio central y su contador son los que importan.
 110
 111 === Subdirectorios Vacíos ===
 112
 113 Los subdirectorios vacíos no pueden ser administrados. Crea archivos dummy para evitar este problema.
 114
 115 La implementación actual de Git, y no su diseño, es quien tiene la culpa de este problema. Con suerte,
 116 una vez que Git gane más tracción, más usuarios van a clamar por
 117 esta funcionalidad y va a ser implementada.
 118
 119 === Commit Inicial ===
 120
 121 El estereotipo de un informático teórico cuenta desde 0, en lugar de desde 1.
 122 Lamentablemente, con respecto a los commit, Git no mantiene esta convención. Muchos
 123 comandos son poco amigables antes del commit inicial. Adicionalmente algunos casos
 124 borde deben ser manejados de forma especial, como hacer rebase de una rama con
 125 un commit inicial distinto.
 126
 127 Git se beneficiaría al definiri el commit cero: tan pronto como se construye un
 128 repositorio, HEAD debería ser un string conteniendo 20 bytes de 0. Este commit especial
 129 representa un árbol vacío, sin padre, que en algún momento es parte de todos los repositorios de Git.
 130
 131 Entonces el correr git log, por ejemplo, informaría al usuario que no se han hecho commits aún,
 132 en lugar de salir con un error fatal. Algo similar pasaría con otras herramientas.
 133
 134 Cada commit inicial es de forma implícita un descendiente de este commit cero.
 135
 136 Lamentablemente igual hay algunos casos que presentan problemas.
 137 Si varias ramas con commits iniciales diferentes se mergean juntas,
 138 entonces un rebase del resultado requiere una buena cantidad de intervención manual.
 139
 140 === Rarezas De La Interfaz ===
 141
 142 Para los commits A y B, el significado de las expresiones "A..B" y "A...B" depende
 143 de si el comando espera dos puntas o un rango. Ver *git help diff* y *git help rev-parse*