... especialmente quando movido por unidades flash USB FAT32 ou exFAT?
Mesmo que a cópia de trabalho provavelmente sofra alterações de permissões e remoção óbvia de links simbólicos (se estiver usando-os)... que são mudanças que o Git irá detectar bem, fora isso,o .git/conteúdo do diretório é suficiente para permitir a movimentação de um repositório de um sistema operacional e/ou sistema de arquivos para outro?por exemplo, Windows, distribuições Linux comuns, macOS, NTFS, ext FS,APFS...
Posso assumir a versão 2+ do Git, se necessário.
Responder1
Sim, o banco de dados do repositório égeralmenteportátil em todos os sistemas operacionais modernos,IncluindoJanelas. Ele não depende de nenhum atributo estendido e, até agora, também não depende de distinção entre maiúsculas e minúsculas. Os nomes de arquivos dentro do banco de dados parecem ter no máximo 52 caracteres.
O principal requisito é que os nomes dos arquivospreservaro caso deles, mesmo em sistemas de arquivos que não diferenciam maiúsculas de minúsculas (por exemplo, se você copiar .git/HEAD de ext4 para FAT32 para APFS para HFS+ para ext4, ele deve permanecer .git/HEAD e não se tornar .git/head). Felizmente todos os sistemas de arquivos listados acimasãopreservação de caso, então tudo bem.
Uma coisa a ter em mente é que cada branch ou tag é representado como um arquivo separado em .git/refs. O Git impõe um limite estrito de conjunto de caracteres para funcionar com qualquer sistema de arquivos, mas isso nem sempre é suficiente - se você estiver migrando para um sistema de arquivos que não diferencia maiúsculas de minúsculas (como APFS ou NTFS), é melhor torcer para que o repositório não contenha múltiplas ramificações ou tags diferindo apenas no caso. Da mesma forma, o Git não proíbe o uso de nomes de dispositivos DOS legados, como auxou nulcomo nomes de ramificações/tags.
(Tecnicamente, mover o repositório entre diferentes sistemas de arquivos pode perder alguns metadados de arquivo, como o a-westado "somente leitura" ( ) de blobs de objetos, mas isso não é algo que o próprio Git analisa de qualquer maneira.)
Se você usar FAT32 apenas como transporte temporário, considere usar git pack-refs --all --prunee rm -rf .git/logspara evitar quaisquer problemas de nome de filial, por mais improváveis que sejam. Execute também um git repack -d; git prunepara reduzir o número de arquivos de objetos soltos.
Você pode até usar git bundlepara criar um blob fácil de transportar contendo todo ou parte do histórico de commits.
Responder2
Embora copiar o .gitdiretório funcione na maioria dos casos, há algumas advertências que precisam de atenção:
O git-svn pode lembrar algumas informações do usuário que você não deseja copiar, como nome e endereço de e-mail, por exemplo, em arquivos
.git/logs/refs/remotes/trunk.Um repositório clonado conterá um link para o pai que o comando de cópia não irá descriar. Você pode remover esse link usando
git remote remove origin.Se você tiver links simbólicos no
.gitdiretório, certifique-se de desreferencia-los. Por exemplo:cp -r -L <source-repo-dir> <destination-repo-dir>Alguns itens de configuração podem variar entre plataformas, como drivers diff personalizados e scripts de gancho que fazem referência a programas externos. Ao copiar entre plataformas diferentes , deve-se verificar itens como
core.ignorecase,core.autocrlf, e provavelmente alguns outros.core.safecrlfcore.fileModeclone é uma operação segura que pode operar entre computadores:
git clone ssh://[email protected]/path/to/my-project.gitA clonagem cria automaticamente uma conexão remota chamada “origem” apontando de volta para o repositório original, facilitando a interação com um repositório central.
Você pode achar interessante ler o seguinte tutorial para mover seletivamente um diretório git: