2011-05-08 15 views

Respuesta

6

Correcto, si el contenido del archivo cambia incluso en un solo bit, tendrá un nuevo nombre de objeto (a.k.a., SHA1sum o hash). Se puede ver el nombre del objeto que la imagen tendrá con git hash-object, si desea probar que:

$ git hash-object text.txt 
9dbcaae0abd0d45c30bbb1a77410fb31aedda806 

Puede encontrar más información sobre cómo se calculan aquí los hashes de manchas:

+3

No tiene sentido decir que el hash de blob es "commit ID", es una identificación del blob. – svick

+1

@svick - identificador de objeto – manojlds

+0

también conocido como 'nombre de objeto' ([' man git-rev-parse'] (http://www.kernel.org/pub/software/scm/git/docs/git-rev- parse.html)). Encuentra todos los que tienen 'git rev-list --objects --all' – sehe

5

Me gustaría agregar a la respuesta de Marcos.

Mientras que Subversion, CVS e incluso Mercurial usan Delta Storage, donde solo almacenan la diferencia entre confirmaciones, Git toma una instantánea del árbol con cada confirmación.

Cuando cambia el contenido de un archivo, se agrega una nueva burbuja para el contenido en el almacén de objetos. A Git solo le importa el contenido en este punto y no el nombre del archivo. El nombre de archivo y la ruta se rastrean a través de objetos de árbol. Cuando un archivo cambia y se agrega al índice, se crean los blobs para el contenido. Cuando se compromete (o utiliza comandos de bajo nivel como git write-tree), el objeto de árbol se actualiza para hacer que el archivo apunte al nuevo contenido. También debe tenerse en cuenta que, si bien cada cambio en un archivo crea un nuevo blob para él, los archivos con el mismo contenido nunca obtendrán blobs diferentes.

Por lo tanto, su pregunta

Si modifica un archivo tiene la versión modificada del archivo obtener su propia burbuja y por lo tanto su propio Sha?

El nuevo contenido obtiene una nueva burbuja y el archivo apunta al nuevo blob. Y también, si el contenido nuevo es igual que un blob anterior, simplemente apunta al anterior.

PD: Hay que señalar que Git "empaqueta" estos "objetos sueltos" en archivos de paquete (donde git almacena deltas de una versión del archivo a la otra) cuando hay demasiados objetos sueltos alrededor, si git gc se ejecuta de forma manual o cuando se envía a un servidor remoto, por lo que puede ser que los archivos se guarden en delta. Mire el capítulo Pro-Git sobre esto para más información - http://progit.org/book/ch9-4.html

+0

¿Algo reducido? La carga general de Git (que incluye todo el historial del repositorio) generalmente es más pequeña que la sobrecarga de SVN (que incluye solo la versión actual). Además, los archivos del paquete usan compresión delta internamente, pero no tiene que ser contra la versión anterior como con SVN. – svick

+0

Lo han reformulado y se ha agregado un enlace al capítulo de programación que lo explica. Una cosa es que en un proyecto que tiene una gran cantidad de archivos binarios que cambian con frecuencia, Git tiende a tener una huella más grande que SVN. Eso es lo que se suponía que quería decir con algo (debería haber sido "la mayoría de las veces", pero lo estaba escribiendo como un script posterior) – manojlds

Cuestiones relacionadas