Git e links físicos

91

Considerando que o Git não reconhece links simbólicos que apontam para fora do repositório, há algum problema em usar links físicos?

O Git poderia quebrá-los? Você pode me indicar informações detalhadas?

— Alfredo Palhares
fonte

2

O que você está tentando fazer e por quê? Um link físico não é diferente de um arquivo normal. Se você puxasse uma nova versão de outro repositório, ele sobrescreveria a que você tinha - de que adianta vincular a algo fora do repositório?

— Carl Norum

1

O Git reconhecerá links simbólicos que apontam para um caminho fora do repositório.

— mipadi,

Não mipadi, a única maneira é agitar os arquivos no repo e os links simbólicos na sua localização "real"

— Alfredo Palhares

84

O objeto 'tree', que representa os diretórios no Git, armazena o nome do arquivo e (subconjunto de) permissões. Ele não armazena o número do inode (ou outro tipo de id de arquivo). Portanto, os hard links não podem ser representados no git , pelo menos não sem ferramentas de terceiros, como metastore ou git-cache-meta (e não tenho certeza se isso é possível mesmo com essas ferramentas).

O Git tenta não mexer nos arquivos que não precisam ser atualizados, mas você deve levar em consideração que o git não tenta preservar os hardlinks, então eles podem ser quebrados pelo git.

Sobre links simbólicos apontando para fora do repositório : git não tem problemas com eles e deve preservar o conteúdo dos links simbólicos ... mas a utilidade de tais links é duvidosa para mim, já que se esses links simbólicos seriam quebrados ou não depende do layout do sistema de arquivos fora do repositório git , e não está sob controle do git.

— Jakub Narębski
fonte

4

Links simbólicos para caminhos fora do repositório podem ser úteis. Eu os usei em aplicativos da web para apontar para banco de dados ou arquivos de mídia não rastreados pelo repo. Dessa forma, o arquivo de configuração do aplicativo da web pode apontar para um caminho estático, mas a localização real desse caminho pode variar entre o desenvolvimento local e os ambientes de servidor.

— mipadi,

@mipadi: BTW. O gitweb moderno tem um caso especial para exibir links simbólicos que levam após a normalização fora do repositório.

— Jakub Narębski

6

Sim, links simbólicos fora do repositório estão bem. Usei-os para apontar para um diretório de dados massivo que eu não precisava (ou queria) versionado. Geralmente eu uso links relativos. Portanto, em alguns casos, o repo e o diretório de dados precisaram estar próximos um do outro em algum diretório pai. Você pode fazer truques incríveis com links simbólicos para ../foo.

— Adrian Ratnapala

Infelizmente, o repositório Git para metastore (git: //git.hardeman.nu/metastore.git) não está mais disponível.

— Derek Mahar

1

github.com/danny0838/git-store-meta é uma alternativa ao git-cache-meta .

— Derek Mahar

21

Descobri que, usando ganchos, você pode capturar o git pullevento (quando há algo para puxar ...) escrevendo o manipulador de eventos do script em um .git/hooks/post-mergearquivo.

Primeiro, você tem que fazer chmod +xisso.

Em seguida, coloque os lncomandos dentro dele para recriar links físicos em cada pull. Legal hein!

Funciona, eu só precisava disso para o meu projeto e ls -imostra que os arquivos foram automaticamente vinculados depois pull.

Meu exemplo de .git/hooks/post-merge:

#!/bin/sh
ln -f $GIT_DIR/../apresentacao/apresentacao.pdf $GIT_DIR/../capa/apresentacao.pdf
ln -f $GIT_DIR/../avaliacoesMono/avaliacao_monografias_2011_Nilo.pdf $GIT_DIR/../capa/avaliacoes.pdf
ln -f $GIT_DIR/../posters/poster_Nilo_sci.pdf $GIT_DIR/../capa/poster.pdf
ln -f $GIT_DIR/../monografia/monografia_Nilo.pdf $GIT_DIR/../capa/monografia_Nilo.pdf

IMPORTANTE: Como você pode ver, o caminho para qualquer arquivo em seu repositório deve começar com e $GIT_DIR, em seguida, adicione o caminho relativo parcial ao arquivo.

Também importante: -fé necessário, porque você está recriando o arquivo de destino.

— Niloct
fonte

11

Portanto, parece que cada vez que você adiciona um hardlink ao seu repo, você também precisa adicionar manualmente uma linha ao seu script de gancho pós-mesclagem. Seria bom se seu gancho pré-commit tornasse isso totalmente automático - detectando links físicos (e simbólicos) em seu commit e escrevendo as linhas apropriadas em seu arquivo pós-mesclagem. O Git não teria que armazenar informações de inode no repo, ele iria armazenar partes delas nos ganchos! Mas que bagunça se o arquivo vinculado fosse rastreado em outro repositório git ... uma edição no arquivo em um lugar se propagaria para outro repositório sem problemas? Perpétua mescla com um loop circular push / pull?

— horas de

Abordagem inteligente, mas é uma pena que o Git não rastreia links físicos, mesmo potencialmente representando-os como cópias em sistemas de arquivos que não suportam links físicos.

— Derek Mahar

8

Deste problema de msysgit

Os pontos de junção não são links simbólicos; portanto, links simbólicos simplesmente não são suportados no msysGit.

Além disso, links físicos nunca foram rastreados pelo Git .

O problema era voltado para o Windows (já que se trata de msysgit) e o debate sobre o suporte potencial do link simbólico.
Mas o comentário sobre hard link diz respeito ao Git em geral.

— VonC
fonte

2

Google 'git preserve hard links' e mostra que git não sabe como preservar a estrutura de hard link AFAIK, talvez por design.

Projetos da minha web usam links físicos da seguinte forma:

www/products/index.php
www/products/dell_latitude_id577/index.php #(hard linked to above)
www/products/dell_inspiron_id323/index.php #(hard linked again to above)

me@server:www/products$ ls -l index.php
-rwxr-xr-x 3 me me 1958 Aug 22 22:10 index.php*

Se eu quiser fazer alterações no index.php, eu o altero em um lugar e os links físicos (páginas de detalhes do produto) apontam para as alterações - exceto que o git não preserva esse relacionamento durante a clonagem e o pull em outros computadores.

me@server:www$ git pull

em outra máquina criará um novo index.php para cada link físico.

— xce_git
fonte

7

Você deve implementar algum tipo de roteamento em seu webapp. Links físicos são bizarros.

— Nowaker

5

Sim, pelo menos use links simbólicos. :)

— Andres Riofrio

2

Isso é realmente o que eu quero, não quero o git para preservar os hard links. Eu tenho um diretório Jenkins com toneladas de diretórios de espaço de trabalho e, devido aos pipelines multibranchos, há muita duplicação. Então, eu tenho um emprego noturno que corre hardlink --ignore-timesobre /var/lib/jenkins, para recuperar algum espaço em disco. Durante o dia, alguns arquivos são desvinculados novamente depois git pullou, mvn compilemas está tudo bem, espero que isso aconteça. Se o git preservasse os links físicos, minha estratégia de reciclagem de espaço em disco não funcionaria.

— Amedee Van Gasse