¿Qué es "creado hace 7 días; comprometido hace 14 horas "¿quiere decir en GitHub?

Estoy viendo esto en este repositorio de GitHub :

ingrese la descripción de la imagen aquí

¿Qué significa esto? ¿Cómo puede algo ser "creado hace 7 días" y, sin embargo, "comprometido hace 14 horas"?

github

— Deshacer
fuente

¿Podría git estar midiendo las marcas de tiempo entre los archivos que editó y cuándo realmente cometió y presionó? No veo un uso para tal característica, pero eso es lo que implica la redacción ..

— Seth

@Seth Eso fue lo que pensé al principio, pero nunca había oído hablar de Git haciendo algo con marcas de tiempo.

— Deshacer

@Seth Git ignora las marcas de tiempo del archivo. El committer puede alterar la marca de tiempo del autor sobre la marcha usando commit --date=. Schwern lo explica muy bien.

— ADTC

@ Deshacer Espero que no estés confundiendo "hace 14 horas" con "hace 14 días" ... Ahora eso sería realmente extraño, tener algo comprometido que aparentemente ni siquiera fue creado hasta 7 días después ... No estoy seguro de si Git impide establecer la marca de tiempo del autor mayor que la marca de tiempo del confirmador; probablemente no le importe.

— ADTC

Respuestas:

Git tiene un concepto separado del autor (la persona que escribió el código) y el confirmador (la persona que lo comprometió en el repositorio). Del mismo modo, puede haber diferentes fechas para ambos. Suelen ser lo mismo.

Desearía que fueran diferentes principalmente si la persona que escribe el código o envía el parche no tiene acceso directo al repositorio como en los proyectos que usan listas de correo para enviar parches. En este caso, la persona con acceso push aplicaría el parche y se ejecutaría git commitcon los modificadores --authory--date o utilizando las variables de entorno GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL y GIT_AUTHOR_DATE (documentado en git-commit-tree .

El otro caso está usando git cherry-pick o git rebase. El responsable es la persona que realiza la selección de cereza, y el autor es el autor del compromiso original. Git se encargará de configurar la identidad del autor y la fecha para usted.

Puede ver esta información en el repositorio con git log --pretty=fuller.

commit 21550561941b078ea1862b882ec89f26696ff5bb (HEAD, origin/master, origin/HEAD, master)
Author:     thiagopnts <thiagopnts@gmail.com>
AuthorDate: Tue Nov 18 14:52:49 2014 -0200
Commit:     Thiago Pontes <email@thiago.me>
CommitDate: Tue Nov 25 09:46:58 2014 -0200

    open repository url if confirmed, closes #1

— Schwern
fuente

git rebasetambién hace que la fecha de confirmación se actualice mientras que la fecha del autor sigue siendo la misma.

— cjm

@cjm Tienes razón! rebase y cherry-pick se comportan igual a este respecto. Eso tiene sentido, un rebase puede considerarse como múltiples selecciones de cereza.

— Schwern

Para aplicar parches desde el correo, también hay git am , que toma automáticamente la fecha y el autor del mensaje de correo.

— deltab

Esto parece una mezcla entre cómo funciona Git con las fechas y cómo se hizo referencia con las palabras clave de cierre de GitHub .

Git separa entre las fechas de confirmación y autor. En Pro Git entran un poco en la diferencia :

El autor es la persona que originalmente escribió el trabajo, mientras que el responsable es la última persona que aplicó el trabajo. Por lo tanto, si envía un parche a un proyecto y uno de los miembros principales aplica el parche, ambos obtendrán crédito: usted como autor y el miembro principal como responsable.

Por lo tanto, aunque el código en sí fue confirmado / escrito "hace 7 días" (localmente), no fue "aplicado" o parcheado al código hasta "hace 14 horas", ya que no se vio en el control remoto hasta que se hizo referencia al cierre mensaje.

— Ocho días de malestar
fuente

Si bien no lo he probado, no creo que Github haya agregado la información del autor al cerrar las palabras clave. El identificador y las identidades y fechas del autor se integran en la ID de confirmación. Si Github cambiara alguno de estos, cambiaría la ID de confirmación en el extremo remoto. Los repositorios remotos y locales divergirían. El autor no podría empujar o tirar sin forzarlo.

— Schwern

Comprometerse no es lo mismo que presionar a distancia. Recuerde que casi todo en Git se puede hacer localmente, incluidas las confirmaciones. Puede confirmar primero (que proporciona ambas marcas de tiempo) y presionar más tarde (que simplemente carga la confirmación en el control remoto pero no proporciona ninguna marca de tiempo). No hay una "marca de tiempo de inserción", ya que no es importante saber cuándo se envió una confirmación; puede ser (y a menudo es) empujada y extraída cualquier cantidad de veces.

— ADTC