git send-email para no alterar las dates de confirmación de git format-patch

Pregunta: ¿Hay alguna manera de decirle a git send-email para honrar las dates de git format-patch ? Mejor aún, ¿hay forma de no considerar la date del correo y la date de compromiso como distintas?

Observaciones: esta es mi observación sobre el tratamiento de las dates para las que no he encontrado la forma de alterar

  1. Los parches creados con el git format-patch tienen la date de compromiso registrada como Date: encabezado.
  2. Al usar git send-email para enviar los parches, la date de confirmación se cambia al momento del envío
  3. Al aplicar las confirmaciones con git am , se usa la date como en Date: encabezado del correo electrónico recibido.

Trabajo parcial parcial: al utilizar un script de contenedor para git send-email , es posible extraer la date de compromiso del parche y usar faketime o un método similar para forzar a git send-email a obedecer la date de confirmación. Esto trae dos problemas, sin embargo:

  1. Debido a que la date del correo y la date de compromiso están contraídas en una (que considero un defecto conceptual), el correo aparecerá en la bandeja de input en el momento incorrecto, lo que es inconveniente.
  2. Solo puedo aplicar fácilmente este método al envío de un parche, no una serie de parches, si deseo que aparezcan en el mismo hilo de correo. Está bien, por supuesto, puedo habilitar la debugging de SMTP ( git send-email --smtp-debug=1 ) y extraer el Message-Id del resultado. Pero luego empieza a parecer que necesito comenzar a reescribir las opciones de enhebrado que ya están implementadas en git send-email

Tenga en count que si git send-email respetara las dates de confirmación registradas por git format-patch entonces podría usar la carta de presentación ( git send-email --cover-letter ) para tratar el problema número 1, confiando en el soporte de enhebrado del git send-email y MUAs.

Pregunta de bonificación: Realmente me gustaría ver las dates de confirmación (implementación) originales en los parches aplicados para el logging (las series de parches fusionados en una confirmación indicarían el momento de incorporación a la twig publicada). ¿Está mi pensamiento de alguna manera equivocado al querer esto? ¿Hay algún pensamiento más profundo en el tratamiento de la date del correo electrónico y la date de compromiso como uno solo? Esto para mí es análogo a impulsar cambios locales a alguna twig pública; las dates se mantienen.

PD: No hay tags git-send-email y git-format-patch que me gustaría usar (la reputación no permitirá su creación).

    Intereting Posts