Pregunta

Tengo un repositorio git (que cubre más o menos la historia del proyecto) y separados fuentes (sólo un archivo tar con unos archivos) que se han bifurcado hace algún tiempo (en realidad en algún lugar en 2004 o 2005).

Las fuentes de tar han sido sometidos a un buen montón de cambios desde la que me gustaría incorporar alguna. Ahora la pregunta es -. La manera de averiguar lo que era en realidad el punto de ramificación de las fuentes modificados para obtener diff mínima de lo que ha ocurrido allí

Así que lo que básicamente quiero es encontrar su lugar en la historia de Git, donde el código es más similar a la tar de las fuentes que tengo. Y yo no quiero hacerlo manualmente.

También vale la pena mencionar que las fuentes modificados sólo incluyen subconjunto de archivos y se han dividido en algunos archivos más. Sin embargo, el código que se encuentra en no parecen tener sólo pequeñas modificaciones y varias adiciones.

Si quieres jugar con eso mismo, el archivo tar con las fuentes es aquí Git y está alojado en Gitorious : git://gitorious.org/gammu/mainline.git

¿Fue útil?

Solución

En el caso general, que había hecho que examinar cada confirmación, ya que no hay manera de saber si es posible que tenga una gran diff en una, pequeña diff la siguiente, a continuación, otro gran diff, a continuación, un diff medio ...

Su mejor apuesta es probablemente va a ser por qué limitarse a archivos específicos. Si se tiene en cuenta sólo un único archivo, no debe tomar mucho tiempo para iterar a través de todas las versiones de ese archivo (uso git rev-list <path> para obtener una lista, por lo que no tiene que probar cada commit). Para cada confirmación que modificó el archivo, se puede comprobar el tamaño del diff, y bastante rápidamente encontrar un mínimo. Haga esto por un puñado de archivos, es de esperar que estará de acuerdo!

La mejor manera de establecer una meta para el diffing es hacer cometer un temporal, simplemente copiando en su archivo comprimido, lo que puede tener una rama llamada tarball el que comparar. De esta manera, se podría hacer esto:

git rev-list path/to/file | while read hash; do echo -n "$hash "; git diff --numstat tarball $hash path/to/file; done

para obtener una buena lista de todos los tamaños confirmaciones con sus diff (las tres primeras columnas serán SHA1, el número de líneas añadidas, y el número de líneas eliminado). Posteriormente, se podría simplemente tubería en en awk '{print $1,$2+$3}' | sort -n -k 2, y que tendría una lista ordenada de confirmaciones y sus tamaños diff!

Si no puede limitarse a un pequeño puñado de archivos a prueba, que podría estar tentado a mano implementar algo similar a git-bisect - simplemente tratar de reducir su camino hacia abajo a un pequeño diff, haciendo la suposición de que en todos probabilidad, se compromete a cerca de su mejor de los casos tendrá también diferenciaciones más pequeños, y se compromete ni mucho menos tendrá diferenciaciones más grandes. (En algún lugar entre el método de Newton y un lleno en la búsqueda binaria / sistema, probablemente?)

Edit: Otra posibilidad, sugerida en respuesta Douglas , si usted piensa que algunos archivos podrían ser idénticos a los que de alguna confirmación, es de hash usando git-hash-object , y luego ver lo que se compromete en su historia tiene que blob. Hay una pregunta con unas excelentes respuestas sobre cómo hacerlo. Si hace esto con un puñado de archivos - de preferencia los que han cambiado con frecuencia -. Usted puede ser capaz de reducir el objetivo comprometerse con bastante rapidez

Otros consejos

No es una buena solución, pero para obtener una estimación de los cuales las revisiones que podría ser: Supongamos que algunos de los archivos de la bola de alquitrán no se han cambiado desde que se ramificados. Ejecutar git de hash objeto uno contra archivo en la bola de alquitrán, a continuación, busque los archivos en el repositorio utilizando git show de . A continuación, tratar de encontrar las confirmaciones bajo las cuales se incluyeron estos archivos, posiblemente usando git WhatChanged . La respuesta a su pregunta podría ser entonces el envío de datos con los archivos más comunes, pero todavía va a ser un poco impredecible.

sobre la base de lo que dijo araqnid me ocurrió con 9c6c864426bf88429e77c7e22b5aa78e9295b97a (sólo pedimos cosas entre 0.61.0 y HEAD), este no es el mejor es probablemente) mejor que podría hacer con algo como

git rev-list --no-merges --all | while read rev; do patchsize=$(git diff $rev | wc -c); echo $patchsize $rev; done | sort -n | less

suponiendo que haya importado el fichero tar en git y tienen esa revisión desprotegido (Hice esto untaring y después

git init
git add .
git commit -m "import tarball"
git remote add origin git://gitorious.org/gammu/mainline.git

Así que después de hacer eso y la pista de lo anterior se debe hacer salir el tamaño de todos los diferenciales con el fin de patchsize ascendente (el primero será 0, ya que encontrará el actual jefe) que va a tomar mucho tiempo ... pero debe encontrar la más pequeña dif ...

cómo se hizo el tenedor? era un clon que alguien más ha hecho y luego hizo su propio trabajo? si es así, entonces esto es realmente fácil. todo lo que tiene que hacer es crear una rama local que tira en el código del tenedor. git ver la ascendencia de la rama en forma de horquilla que apunta a una de las confirmaciones de su repositorio original y se "conectar los puntos" por así decirlo ... que se volverá a conectar la historia de su repositorio original al tenedor.

que debe ser capaz de hacer esto:

git remote add thefork git://wherever.it.lives/thefork.git

git fetch thefork

git branch -f thefork-branch thefork/branchname

git checkout thefork-branch

En este punto, puede ejecutar gitk y ver la historia completa de la rama bifurcada y su repositorio local, y ver si se conectan o no.

Importar que contenido del archivo comprimido a una revisión git, en una rama separada o uno completamente nuevo:. La posición en el gráfico de revisiones no es importante, sólo queremos que esté disponible como un árbol

Ahora, para cada revisión en el maestro, solo diff contra ese árbol / revisión ( 'importados') y la salida de lo grande que es el diff. Algo así como:

git rev-list master | while read rev; do patchsize=$(git diff $rev imported | wc -c); echo $rev $patchsize; done

Así que la revisión con el tamaño más pequeño parche será el "más cercano", por una regla muy general del pulgar. (Una revisión idénticos producirá un tamaño del parche de 0, y cualquier otra cosa será sin duda no es cero, y el más que ha cambiado, el más grande).

Si usted tiene una idea aproximada de dónde se produjo el tenedor, considere el uso de Will Manley git meld . (Véase también: Ver diferencias de ramas con MELD ?).

Para ello, agregue el contenido tarball a su repositorio (que se va a hacer de todos modos). Después de instalar Meld y git-meld, ejecute

git meld branch_from_tarball commit_to_check &

en diferentes confirmaciones hasta que encuentre el que tiene menos diferencias. Este comando abrirá meld y ver los cambios en el árbol de directorios entre las confirmaciones especificados, con los archivos ocultos idénticos. Ejemplo capturas de pantalla:

Meld muestra dos confirmaciones muy diferentes:
muy diferente

Mostrando dos confirmaciones similares: similares

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top