¿Qué sucede con las marcas de time del file al realizar la fusión de git?

Cuando hago una fusión de git, ¿es un comportamiento estándar que git establezca una nueva timestamp en todos los files fusionados? Entonces, ¿la timestamp original de un file solo existe en la twig original donde se modificó / creó el file?

Como se menciona en un comentario , Git (en su mayoría) no usa ni se preocupa por las marcas de time en los files.

Git mantiene una timestamp por compromiso. Más precisamente, mantiene dos : una timestamp de autor y una timestamp committer. Pero esto no tiene ningún efecto en las marcas de time del file en absoluto. En cambio, Git los deja al sistema operativo subyacente. Si Git debe actualizar un file, simplemente lo hace: escribe en el file y permite que el sistema operativo cambie la timestamp de modificación del file a "ahora" como efecto secundario. Si Git debe leer un file, simplemente lo hace y permite que el sistema operativo cambie la timestamp de acceso del file a "ahora" como efecto secundario. La timestamp que más le importa a la mayoría de la gente es el time de modificación. 1

Por lo tanto, git merge toca un file en el tree de trabajo, actualizando su timestamp a "ahora", si y solo si necesita escribir en el file como resultado de la fusión. Entonces la pregunta realmente se networkinguce a "¿por qué Git necesitaba escribir en el file para fusionarlo?" La respuesta a eso aparece en sus comentarios: la modificación se debe a terminaciones de línea alteradas.

Merge funciona al encontrar una combinación de combinación común. Este compromiso base de fusión es donde el historial de su confirmación actual ( HEAD ) se une con el historial de la confirmación que está fusionando. Git luego ejecuta dos git diff , una de la base de fusión a su compromiso: esto descubre "lo que ha cambiado" para "las" y una de la base de fusión a la otra confirmación, para averiguar para qué han cambiado --theirs La acción de fusión, la forma verbal de "fusionar", consiste en combinar estos dos sets de cambios. 2

Si un set de cambios es "cambiar finales de línea", y esto toca al less una línea en cada file, tiene sentido que cada file sea alterado por el process de fusión. Pero tenga en count que Git puede modificar las terminaciones de línea por sí mismo, a través de la core.autocrlf y / o .gitattributes . El código de git merge tiene un caso especial dentro de él, controlado por la configuration de configuration merge.renormalize , o por las opciones de command-line -X renormalize o -X no-renormalize . El uso completo de esto está más allá del scope de esta respuesta, pero el objective de la bandera de renormalización es específicamente permitir que este tipo de fusión funcione sin tener que tocar cada línea.


1 Hay hasta cuatro sellos de time totales por file, según el sistema operativo y el sistema de files: el "time de acceso", llamado st_atime en una struct stat ; el "time de modificación", st_mtime ; un time de "cambio", un time de "inicio" y un time de "nacimiento", el momento en que se creó el file, llamado st_birthtime o st_birthtimespec . La hora de modificación y el time de cambio son similares, pero no iguales: por ejemplo, al cambiar el modo de un file, para agregar o eliminar el bit de ejecución, se cambia el st_ctime pero no el st_mtime . Este cambio de modo es un cambio en la información sobre el file que no cambia el contenido del file. La mayoría de los sistemas operativos también permiten a los usuarios configurar los times de acceso y modificación arbitrariamente, utilizando una familia de llamadas al sistema utime o utimes ; la actualización de estos times establece el ctime a "ahora".

2 Eventualmente, después de la combinación, Git normalmente pasa a realizar un commit de fusión -el adjetivo o incluso el sustantivo de "merge", ya que "un commit de fusión" a menudo se abrevia simplemente como "merge". Una combinación, o un compromiso de fusión, es un compromiso con un historial bifurcado: apunta no solo al compromiso HEAD anterior, sino también a su compromiso, el que fue la fuente de --theirs , durante la fusión. Este compromiso de fusión sirve para unir las dos historias y, por lo tanto, afecta a todas las combinaciones futuras , ya que las dos historias ahora se unen en ese punto, en lugar de en un punto anterior. En otras palabras, este merge-as-a-noun crea una nueva base de fusión para futuras fusiones.