Copie una única confirmación desde otra twig, sin nuevas confirmaciones

La forma más similar de hacerlo es:

git cherry-pick COMMIT_HASH

Pero esto crea un nuevo compromiso. Entonces cuando me fusiono obtengo dos commits idénticos con hashes diferentes.

No es posible.

El ID de una confirmación es una sum de comprobación criptográfica única de los contenidos de la confirmación, que debe hacer que pregunte inmediatamente: "¿Cuáles son los contenidos de una confirmación?"

Para responder eso, eche un vistazo a una confirmación de muestra:

 $ git cat-file -p HEAD 

por ejemplo. Verás algo en esta línea:

 tree 80e2d6ce407585c136ab90a6aba1fcb807e7e042 parent 31305025f20182017855793ebce8b122b1396246 author AU Thor <thor@example.com> 1475588570 -0700 committer AU Thor <thor@example.com> 1475588740 -0700 commit message 

Eso, literalmente (aunque en este caso con algunas ediciones), es el contenido completo de una confirmación: una línea de tree , algunas líneas parent (generalmente solo una), una línea de author , una línea de committer , una línea en blanco y su compromiso post.

Supongamos que copy algún otro compromiso, incluso hasta usar el mismo tree (el tree es el ID de un object Git único que representa la instantánea que hace Git de su tree de trabajo 1 ). Supongamos que de alguna manera engañas a Git para que ponga el mismo sello de time, aunque probablemente sean días, u horas, o incluso unos pocos segundos más tarde ahora, de lo que era cuando hiciste ese otro compromiso. Supongamos que también copy el post de confirmación exactamente. Sin embargo, si estás en una twig diferente con una confirmación actual diferente, la línea parent de la nueva copy será diferente.

La línea parent le dice a Git qué compromiso viene inmediatamente antes de cualquier compromiso determinado. Por lo tanto, cada nueva confirmación hace que el nombre de la sucursal apunte a la nueva confirmación, mientras que la nueva confirmación apunta al compromiso anterior. La identificación única de una confirmación depende no solo de la instantánea de origen, el autor y el nombre del comitente / correo electrónico / timestamp, y el post de confirmación. También depende de la ID de confirmación previa , que a su vez depende de su propia ID de confirmación anterior, y así sucesivamente en todo el path de return en la historia.

En otras palabras, el ID de confirmación único no solo identifica solo una confirmación específica, sino que también especifica el historial completo : los ID de cada confirmación que conduce a esa confirmación concreta.


1 Más precisamente, el tree está hecho de los contenidos del índice / área de ensayo. Es por eso que necesita git add cambios en el área de ensayo: si no lo hace, los files modificados no estarán en la siguiente confirmación.

Intenta usar no-commit para eso:

 git cherry-pick --no-commit COMMIT_HASH 

Esto debería get los cambios de esa confirmación, pero se detiene justo antes de comprometerlos desde el área de preparación.