¿Cómo puedo cambiar la confirmación apuntada por una label firmada?

Específicamente, conservando el post y la date de anotación de la label.

Anoche, creé una label firmada para un repository en el que estoy trabajando. Unos minutos más tarde, modifiqué sin pensar el compromiso que había labeldo. Ahora, me estoy preparando para impulsar mis cambios y necesito limpiar esa label antes que yo.

Al ver una pregunta similar (ish) , intenté varias combinaciones de GIT_AUTHOR_DATE y GIT_COMMITER_DATE sin suerte:

 $ git show v0.1.1 | awk '{ if ($1 == "Date:") { print substr($0, index($0, $3)) } }' Nov 26 18:14:17 2017 -0800 Nov 26 18:13:21 2017 -0800 $ git tag -d v0.1.1 Deleted tag 'v0.1.1' (was d4189a2) $ GIT_AUTHOR_DATE="Nov 26 18:14:17 2017 -0800" \ > GIT_COMMITER_DATE="Nov 26 18:14:17 2017 -0800" \ > git tag v0.1.1 9aa951c -s -m 'Display in columns.' $ git show v0.1.1 | awk '{ if ($1 == "Date:") { print substr($0, index($0, $3)) } }' Nov 27 13:34:16 2017 -0800 Nov 26 21:18:34 2017 -0800 

¿Cómo puedo "arreglar" esta label?

En general, estás allí: estás haciendo una nueva label anotada y firmada. Solo tienes un error tipográfico:

 GIT_COMMITER_DATE="Nov 26 18:14:17 2017 -0800" \ 

Esto debería decir:

 GIT_COMMITTER_DATE="Nov 26 18:14:17 2017 -0800" \ 

(dos T en "committer"). Pero no hay una razón obvia para forzar la devolución del sello de la label, ya que ya está haciendo una label nueva y diferente: también podría hacer una nueva label con la timestamp de hoy.

Discusión

Debe crear una nueva label firmada (utilizando, si lo desea, contenidos muy similares y quizás incluso el mismo nombre de label, aunque antes de volver a utilizar un nombre de label, debe leer la discusión de documentation sobre el tema ). El problema aquí es que la firma es en sí misma una afirmación criptográfica sobre el contenido de la label, incluido el post de la label y el hash de confirmación del objective de la label . Esto significa que en la nueva label firmada, debe tener una firma diferente.

Como se trata de una label nueva y diferente, si existe la posibilidad de que alguien más tenga la label anterior, es mejor darle un nuevo nombre a la nueva label (ver la discusión relacionada). Si no hay tal posibilidad, simplemente puede sobrescribir la label anterior con -f . Las variables de entorno especiales de Git se pueden usar para anular las marcas de time pnetworkingeterminadas.

En mis testings, la syntax que GIT_COMMITTER_DATE no hace que la variable GIT_COMMITTER_DATE visible para el siguiente command de git . Tuve mejor suerte con

 export GIT_COMMITTER_DATE=... 

que, por supuesto, querrías desactivar luego de ejecutar git. Puede haber otras forms de taquigrafía; esto es lo que funcionó para mí.

También asegúrese de estar usando un formatting de date reconocido. "YYYY-MM-DD hh:mm:ss" funcionó para mí.

Por cierto, no creo que la "date del autor" importe; AFAIK (y en lo que respecta a los documentos) una label solo se preocuparía por una date. En su salida, la segunda date proviene de la confirmación subyacente (como se puede ver en la salida del show no procesado).

Entonces todo eso dijo, una pregunta … ¿por qué? Si el compromiso modificado se realizó "irreflexivamente", ¿por qué no utilizar el reflog para retroceder y comprometer sus otros cambios como una confirmación separada? O bien, ¿por qué es tan importante que la date de la label sea retroactiva de todos modos?