O que é “escrito há 7 dias; cometido há 14 horas ”significa no GitHub?

Estou vendo isso neste repositório GitHub :

insira a descrição da imagem aqui

O que isto significa? Como algo pode ser "criado há 7 dias" e ainda "comprometido há 14 horas"?

github

— Desfazer
fonte

O git poderia medir os registros de data e hora entre os arquivos que ele editou e quando ele realmente confirmou e enviou? Eu não vejo um uso para esse recurso um, mas isso é meio que o texto implica ..

— Seth

@Seth Isso é o que eu pensava no começo, mas eu nunca tinha ouvido falar do Git fazendo algo com timestamps.

— Desfazer

@Seth Git ignora os registros de data e hora do arquivo. O comunicador pode alterar o carimbo de data / hora do autor on-the-fly usando commit --date=. Schwern explica isso muito bem.

— ADTC

@Undo Espero que você não esteja confundindo "14 horas atrás" com "14 dias atrás" ... Agora isso seria realmente estranho, ter algo comprometido que aparentemente ainda nem foi criado até sete dias depois ... não tenho certeza se o Git impede a configuração do registro de data e hora do autor maior que o registro de data e hora do commit; provavelmente não se importa.

— ADTC

Respostas:

O Git tem um conceito separado do autor (a pessoa que escreveu o código) e o committer (a pessoa que o submeteu ao repositório). Da mesma forma, pode haver datas diferentes para ambos. Eles geralmente são os mesmos.

Você gostaria que eles fossem diferentes principalmente se a pessoa que escrever o código ou enviar o patch não tiver acesso por push ao repositório como nos projetos que usam listas de discussão para envio de patches. Neste caso, a pessoa com acesso impulso iria aplicar o patch e correr git committanto com os --authore --dateinterruptores ou usando as variáveis de ambiente GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL e GIT_AUTHOR_DATE (documentado em git-commit-árvore .

O outro caso é usando git cherry-pickou git rebase. O committer é a pessoa que faz a escolha da cereja e o autor é o autor do commit original. O Git cuidará da configuração da identidade e data do autor para você.

Você pode ver essas informações no repositório com 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 rebasetambém faz com que a data de confirmação seja atualizada enquanto a data do autor permanece a mesma.

— CJM

@cjm Você está certo! rebase e cherry-pick se comportam da mesma maneira a esse respeito. Isso faz sentido, uma recuperação pode ser considerada como várias escolhas de cereja.

— Schwern 26/11/14

Para aplicar patches do correio, há também o git am , que pega automaticamente a data e o autor da mensagem.

— Deltab

Parece uma mistura entre como o Git funciona com datas e como foi referenciado com as palavras-chave de fechamento do GitHub .

Git separa entre datas de confirmação e autor. No Pro Git, eles entram um pouco na diferença :

O autor é a pessoa que originalmente escreveu o trabalho, enquanto o autor é a pessoa que aplicou o trabalho pela última vez. Portanto, se você enviar um patch para um projeto e um dos membros principais aplicá-lo, os dois receberão crédito - você como autor e o membro principal como committer.

Portanto, enquanto o código em si foi confirmado / gravado "7 dias atrás" (localmente), ele não foi "aplicado" ou corrigido no código até "14 horas atrás", pois não foi visto no controle remoto até o fechamento referenciado mensagem.

— Oito Dias de Mal-estar
fonte

Embora não o tenha testado, não acredito que as informações do autor tenham sido adicionadas pelo Github ao fechar as palavras-chave. As identidades e datas do autor e do autor são inseridas no ID de confirmação. Se o Github alterasse alguma dessas opções, a ID de confirmação seria alterada na extremidade remota. Os repositórios remotos e locais divergiriam. O autor seria incapaz de empurrar ou puxar sem forçá-lo.

— 26414 Schwern

Confirmar não é o mesmo que enviar para remoto. Lembre-se de que quase tudo no Git pode ser feito localmente, incluindo confirmações. Você pode confirmar primeiro (que fornece os dois registros de data e hora) e enviar mais tarde (que apenas carrega o commit no controle remoto, mas não fornece nenhum registro de data e hora). Não existe um 'carimbo de data / hora do envio', pois não é importante saber quando um envio foi enviado - ele pode ser (e geralmente é) enviado e retirado várias vezes.

— ADTC