Cosa significa "creato 7 giorni fa; impegnato 14 ore fa "significa su GitHub?

Sto vedendo questo su questo repository GitHub :

inserisci qui la descrizione dell'immagine

Cosa significa questo? Come può qualcosa essere "creato 7 giorni fa" e tuttavia "commesso 14 ore fa"?

github

— Disfare
fonte

Git potrebbe misurare i timestamp tra i file che ha modificato e quando ha effettivamente eseguito il commit e il push? Non vedo un uso per tale funzionalità, ma è un po 'quello che la formulazione implica ..

— Seth,

@Seth Questo è quello che ho pensato all'inizio, ma non avevo mai nemmeno sentito parlare di Git fare qualcosa con i timestamp.

— Annulla il

@Seth Git ignora i timestamp dei file. Il committer può modificare il timestamp dell'autore al volo usando commit --date=. Schwern lo spiega molto bene.

— ADTC,

@Undo Spero che tu non stia confondendo "14 ore fa" con "14 giorni fa" ... Ora sarebbe davvero strano, avere qualcosa di commesso che apparentemente non era nemmeno stato ancora creato fino a 7 giorni dopo ... Io ' non sono sicuro che Git impedisca di impostare il timestamp dell'autore su un valore superiore al timestamp del committer; probabilmente non gliene importa.

— ADTC,

Risposte:

Git ha un concetto separato dell'autore (la persona che ha scritto il codice) e del committer (la persona che lo ha impegnato nel repository). Allo stesso modo ci possono essere date diverse per entrambi. Di solito sono uguali.

Vorresti che fossero diversi principalmente se la persona che scriveva il codice o inviava la patch non ha accesso push al repository come nei progetti che usano mailing list per l'invio di patch. In questo caso, la persona con accesso push applica la patch ed esegue git commitcon gli switch --authore--date o usando le variabili di ambiente GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL e GIT_AUTHOR_DATE (documentate in git-commit-tree .

L'altro caso sta usando git cherry-picko git rebase. Il committer è la persona che effettua la scelta della ciliegia e l'autore è l'autore del commit originale. Git gestirà l'impostazione dell'identità e della data dell'autore per te.

Puoi vedere queste informazioni nel repository 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
fonte

git rebasecausa anche l'aggiornamento della data di commit mentre la data dell'autore rimane la stessa.

— cjm,

@cjm Hai ragione! rebase e cherry-pick si comportano entrambi allo stesso modo. Questo ha senso, un rebase può essere pensato come una scelta multipla di ciliegie.

— Schwern,

Per applicare le patch dalla posta, c'è anche git am , che prende automaticamente la data e l'autore dal messaggio di posta.

— deltab,

Sembra un mix tra il modo in cui Git funziona con le date e il modo in cui è stato referenziato con le parole chiave di chiusura di GitHub .

Git separa tra date di commit e date dell'autore. In Pro Git vanno un po 'nella differenza :

L'autore è la persona che ha originariamente scritto l'opera, mentre il committer è la persona che ha applicato per l'ultima volta l'opera. Quindi, se invii una patch a un progetto e uno dei membri principali applica la patch, entrambi ottieni credito: tu come autore e il membro principale come committer.

Quindi, mentre il codice stesso è stato eseguito il commit / scritto "7 giorni fa" (localmente), non è stato "applicato" o corretto al codice fino a "14 ore fa", dal momento che non è stato visto nel telecomando fino a quel riferimento chiuso Messaggio.

— Otto giorni di malessere
fonte

Anche se non l'ho testato, non credo che le informazioni sull'autore siano state aggiunte dalle parole chiave di chiusura di Github. Le identità e le date del committer e dell'autore sono inserite nell'ID commit. Se Github avesse modificato uno di questi, questo avrebbe cambiato l'ID di commit sull'estremità remota. I repository remoti e locali divergerebbero. L'autore non sarebbe in grado di spingere o tirare senza forzarlo.

— Schwern,

Commettere non è lo stesso che spingere sul telecomando. Ricorda che quasi tutto in Git può essere fatto localmente, inclusi gli commit. Puoi eseguire il commit prima (che fornisce entrambi i timestamp) e premere in seguito (che carica semplicemente il commit su remoto ma non fornisce alcun timestamp). Non esiste un "timestamp push" in quanto non è importante sapere quando è stato eseguito il push di un commit: può essere (e spesso viene) spinto e tirato un numero qualsiasi di volte.

— ADTC,