Aparentemente, cuando mueve una función de un archivo de código fuente a otro, el registro de revisión de git (para el nuevo archivo) puede mostrarle de dónde proviene originalmente ese fragmento de código (consulte, por ejemplo, la sección Historial de visualización en this tutorial).¿Cómo rastrea git el código fuente movido entre archivos?
¿Cómo funciona esto?
No los rastrea. Esa es la belleza de eso.
Git solo graba instantáneas de todo el árbol del proyecto: así es como todos los archivos parecían antes de la confirmación y así es como se ven después. Como llegamos de aquí para allá, a Git no le importa.
Esto permite que se escriban herramientas inteligentes después de una confirmación ya ha ocurrido, para extraer información de esa confirmación. Por ejemplo, la detección de cambio de nombre en Git se hace comparando todos los archivos eliminados con todos los archivos nuevos y comparando las mediciones de similitud por pares. Si la métrica de similitud es mayor que x, se consideran renombrados, si se encuentra entre y y x (y < x), se considera una edición de renombre +, y si está por debajo de y, se consideran independientes. Lo bueno es que usted, como "arqueólogo de compromiso", puede especificar después del hecho, qué x y y deberían ser. Esto no funcionaría si el compromiso simplemente registrara "este archivo es un cambio de nombre de ese archivo".
La detección de contenido movido funciona de manera similar: divide cada archivo en pedazos, calcula las métricas de similitud entre todos los sectores y puede deducir que este segmento que se eliminó aquí y este segmento muy similar que se agregó son los mismos rebanada que se movió de aquí para allá.
Sin embargo, como tonfa se menciona en su respuesta, esto es muy caro, por lo que normalmente no se hace. Pero podría hacerse, y ese es el punto.
Por cierto: esto es casi exactamente lo contrario del modelo de transformación operacional utilizado por Google Wave, EtherPad, Gobby, SubEthaEdit, ACE y Co
Es puramente una heurística. Compara la distancia entre archivos e intenta encontrar bloques coincidentes. Pero esta heurística solo se implementa cuando el código se copia o se mueve a un nuevo archivo (de lo contrario, sería demasiado costoso verificar cada par de archivos).
No lo entiendo * "Esa es la belleza" *. Quiero decir, tu explicación suena a * "¡Git no almacena lo que realmente le sucede a los archivos para que puedas adivinarlo más tarde tú mismo!" * ¿Dónde está la belleza? – Kos
En mi opinión, la belleza de esto es la constatación de que el seguimiento no debe ser parte del control de la versión central en sí. El "Outsourcing" de esta característica evita muchas de las complicaciones y deficiencias de, p. SVN. Obtiene simplicidad y flexibilidad (las herramientas SVN normalmente están restringidas a la utilización de la información de seguimiento que se grabó originalmente, aunque esto podría no ser una buena representación de lo que realmente sucedió con la base de código). – nikow
Kos, no tienes que adivinarlo más tarde. Git tiene heurística para detectarlo cuando es importante (es decir, cuando se fusiona). –