ATUALIZAÇÃO : minha solução agora está incluída em Debian / Ubuntu / Mint, Fedora, Gentoo e possivelmente outras distros:
https://github.com/MestreLion/git-tools#install
sudo apt install git-restore-mtime # Debian/Ubuntu/Mint
yum install git-tools # Fedora/ RHEL / CentOS
emerge dev-vcs/git-tools # Gentoo
IMHO, não armazenar carimbos de data / hora (e outros metadados como permissões e propriedade) é uma grande limitação do git.
A lógica de Linus de que os carimbos de data / hora são prejudiciais apenas porque "confundem make" é falha :
make clean é o suficiente para resolver quaisquer problemas.
Aplica-se apenas a projetos que usam make, principalmente C / C ++. É completamente discutível para scripts como Python, Perl ou documentação em geral.
Só há dano se você aplicar os carimbos de data / hora. Não haveria mal nenhum em armazená- los no repositório. Aplicá-los pode ser uma --with-timestampsopção simples para git checkoute amigos ( clone, pulletc), a critério do usuário .
Tanto o Bazaar quanto o Mercurial armazenam metadados. Os usuários podem aplicá-los ou não no check-out. Mas no git, como os timestamps originais nem mesmo estão disponíveis no repo, essa opção não existe.
Então, para um ganho muito pequeno (não ter que recompilar tudo) que é específico para um subconjunto de projetos, gitcomo um DVCS geral foi danificado , algumas informações sobre os arquivos são perdidas e, como Linus disse, é INFEASÍVEL fazer Isso agora. Triste .
Dito isso, posso oferecer 2 abordagens?
1 - http://repo.or.cz/w/metastore.git , de David Härdeman. Tenta fazer o que git deveria ter sido feito em primeiro lugar : armazena metadados (não apenas timestamps) no repositório ao fazer commit (via gancho de pré-confirmação) e os reaplica ao puxar (também por meio de ganchos).
2 - Minha versão humilde de um script que usei antes para gerar tarballs de lançamento. Conforme mencionado em outras respostas, a abordagem é um pouco diferente : aplicar para cada arquivo o carimbo de data / hora do commit mais recente em que o arquivo foi modificado.
- git-restore-mtime , com muitas opções, suporta qualquer layout de repositório e roda em Python 3.
Abaixo está uma versão realmente básica do script, como uma prova de conceito, no Python 2.7. Para uso real, recomendo fortemente a versão completa acima:
#!/usr/bin/env python
# Bare-bones version. Current dir must be top-level of work tree.
# Usage: git-restore-mtime-bare [pathspecs...]
# By default update all files
# Example: to only update only the README and files in ./doc:
# git-restore-mtime-bare README doc
import subprocess, shlex
import sys, os.path
filelist = set()
for path in (sys.argv[1:] or [os.path.curdir]):
if os.path.isfile(path) or os.path.islink(path):
filelist.add(os.path.relpath(path))
elif os.path.isdir(path):
for root, subdirs, files in os.walk(path):
if '.git' in subdirs:
subdirs.remove('.git')
for file in files:
filelist.add(os.path.relpath(os.path.join(root, file)))
mtime = 0
gitobj = subprocess.Popen(shlex.split('git whatchanged --pretty=%at'),
stdout=subprocess.PIPE)
for line in gitobj.stdout:
line = line.strip()
if not line: continue
if line.startswith(':'):
file = line.split('\t')[-1]
if file in filelist:
filelist.remove(file)
#print mtime, file
os.utime(file, (mtime, mtime))
else:
mtime = long(line)
# All files done?
if not filelist:
break
O desempenho é bastante impressionante, mesmo para projetos de monstro wine, gitou mesmo o kernel linux:
bash
# 0.27 seconds
# 5,750 log lines processed
# 62 commits evaluated
# 1,155 updated files
git
# 3.71 seconds
# 96,702 log lines processed
# 24,217 commits evaluated
# 2,495 updated files
wine
# 13.53 seconds
# 443,979 log lines processed
# 91,703 commits evaluated
# 6,005 updated files
linux kernel
# 59.11 seconds
# 1,484,567 log lines processed
# 313,164 commits evaluated
# 40,902 updated files