Est-ce que mon mieux sera un script shell qui remplace les liens symboliques par des copies, ou existe-t-il une autre façon de dire à Git de suivre les liens symboliques?

PS: Je sais que ce n'est pas très sécurisé, mais je ne veux le faire que dans quelques cas spécifiques.

REMARQUE: cet avis est désormais obsolète selon le commentaire depuis Git 1.6.1. Git se comportait de cette façon et ne le fait plus.

Git essaie par défaut de stocker les liens symboliques au lieu de les suivre (par souci de compacité, et c'est généralement ce que les gens veulent).

Cependant, j'ai accidentellement réussi à le faire ajouter des fichiers au-delà du lien symbolique lorsque le lien symbolique est un répertoire.

C'est à dire:

  /foo/
  /foo/baz
  /bar/foo --> /foo
  /bar/foo/baz

en faisant

 git add /bar/foo/baz

cela a semblé fonctionner quand je l'ai essayé. Ce comportement n'était cependant pas souhaité par moi à l'époque, donc je ne peux pas vous donner d'informations au-delà de cela.

Ce que j'ai fait pour ajouter les fichiers d'un lien symbolique dans Git (je n'ai pas utilisé de lien symbolique mais):

sudo mount --bind SOURCEDIRECTORY TARGETDIRECTORY

Exécutez cette commande dans le répertoire géré par Git. TARGETDIRECTORYdoit être créé avant d' SOURCEDIRECTORYy être monté.

Cela fonctionne bien sous Linux, mais pas sous OS X! Cette astuce m'a également aidé avec Subversion. Je l'utilise pour inclure des fichiers à partir d'un compte Dropbox, où un webdesigner fait son travail.

Pourquoi ne pas créer des liens symboliques dans l'autre sens? Au lieu de lier le référentiel Git au répertoire d'application, il suffit de lier l'inverse.

Par exemple, disons que je configure une application installée dans ~/applicationqui a besoin d'un fichier de configuration config.conf:

• J'ajoute config.confà mon référentiel Git, par exemple, à ~/repos/application/config.conf.
• Ensuite, je crée un lien symbolique à partir de ~/applicationen cours d'exécution ln -s ~/repos/application/config.conf.

Cette approche peut ne pas toujours fonctionner, mais elle a bien fonctionné jusqu'à présent.

Utilisez plutôt des liens physiques. Cela diffère d'un lien souple (symbolique). Tous les programmes, y compris git, traiteront le fichier comme un fichier normal. Notez que le contenu peut être modifié en modifiant soit la source ou la destination.

Sur macOS (avant 10.13 High Sierra)

Si vous avez déjà installé git et Xcode, installez hardlink . C'est un outil microscopique pour créer des liens durs .

Pour créer le lien dur, simplement:

hln source destination

mise à jour macOS High Sierra

Le système de fichiers Apple prend-il en charge les liens matériels des répertoires?

Les liens matériels d'annuaire ne sont pas pris en charge par Apple File System. Tous les liens matériels de répertoire sont convertis en liens symboliques ou alias lorsque vous convertissez des formats de volume HFS + en APFS sur macOS.

De la FAQ APFS sur developer.apple.com

Suivez https://github.com/selkhateeb/hardlink/issues/31 pour de futures alternatives.

Sous Linux et autres versions Unix

La lncommande peut créer des liens durs:

ln source destination

Sous Windows (Vista, 7, 8,…)

Quelqu'un a suggéré d'utiliser mklink pour créer une jonction sous Windows, mais je ne l'ai pas essayé:

mklink /j "source" "destination"

Il s'agit d'un hook de pré-validation qui remplace les objets blob de liens symboliques dans l'index, par le contenu de ces liens symboliques.

Mettez cela .git/hooks/pre-commit, et rendez-le exécutable:

#!/bin/sh
# (replace "find ." with "find ./<path>" below, to work with only specific paths)

# (these lines are really all one line, on multiple lines for clarity)
# ...find symlinks which do not dereference to directories...
find . -type l -exec test '!' -d {} ';' -print -exec sh -c \
# ...remove the symlink blob, and add the content diff, to the index/cache
    'git rm --cached "$1"; diff -au /dev/null "$1" | git apply --cached -p1 -' \
# ...and call out to "sh".
    "process_links_to_nondir" {} ';'

# the end

Remarques

Nous utilisons autant que possible des fonctionnalités conformes à POSIX; cependant, diff -an'est pas compatible POSIX, peut-être entre autres.

Il peut y avoir des erreurs / erreurs dans ce code, même s'il a été quelque peu testé.

Sur MacOS(j'ai Mojave / 10.14, gitversion 2.7.1), utilisez bindfs.

brew install bindfs

cd /path/to/git_controlled_dir

mkdir local_copy_dir

bindfs </full/path/to/source_dir> </full/path/to/local_copy_dir>

Il a été laissé entendre par d'autres commentaires, mais n'est pas clairement fourni dans d'autres réponses. Espérons que cela fera gagner du temps à quelqu'un.

J'avais l'habitude d'ajouter des fichiers au-delà des liens symboliques depuis un certain temps maintenant. Cela fonctionnait très bien, sans prendre de dispositions spéciales. Depuis que j'ai mis à jour vers Git 1.6.1, cela ne fonctionne plus.

Vous pourrez peut-être passer à Git 1.6.0 pour que cela fonctionne. J'espère qu'une future version de Git aura un indicateur lui git-addpermettant de suivre à nouveau les liens symboliques.

Je me suis fatigué que chaque solution ici soit obsolète ou nécessitant un root, j'ai donc créé une solution basée sur LD_PRELOAD (Linux uniquement).

Il se connecte aux internes de Git, remplaçant le "est-ce un lien symbolique?" , permettant aux liens symboliques d'être traités comme leur contenu. Par défaut, tous les liens vers l'extérieur du référentiel sont en ligne; voir le lien pour plus de détails.

Avec Git 2.3.2+ (T1 2015), il y a un autre cas où Git ne suivra plus le lien symbolique: voir commit e0d201b par Junio ​​C Hamano ( gitster) (mainteneur principal de Git)

apply: ne touchez pas un fichier au-delà d'un lien symbolique

Étant donné que Git suit les liens symboliques en tant que liens symboliques, un chemin qui a un lien symbolique dans sa partie principale (par exemple path/to/dir/file, oùpath/to/dir trouve un lien symbolique vers un autre endroit, que ce soit à l'intérieur ou à l'extérieur de l'arborescence de travail) ne peut jamais apparaître dans un patch qui s'applique valablement. , sauf si le même patch supprime d'abord le lien symbolique pour permettre la création d'un répertoire à cet endroit.

Détectez et rejetez un tel patch.

De même, lorsqu'une entrée crée un lien symbolique path/to/dirpuis crée un fichier path/to/dir/file, nous devons le signaler comme une erreur sans réellement créer de path/to/dirlien symbolique dans le système de fichiers.

Au lieu de cela, pour tout correctif dans l'entrée qui laisse un chemin (c'est-à-dire une non suppression) dans le résultat, nous vérifions tous les chemins principaux par rapport à l'arborescence résultante que le correctif créerait en inspectant tous les correctifs dans l'entrée, puis la cible du correctif l'application (soit l'index, soit l'arbre de travail).

De cette façon, nous:

• attraper un méfait ou une erreur pour ajouter un lien symbolique path/to/diret un fichier path/to/dir/fileen même temps,
• tout en autorisant un correctif valide qui supprime un symbole link path/to/dirpuis ajoute un fichier path/to/dir/file.

Cela signifie que, dans ce cas, le message d'erreur ne sera pas générique "%s: patch does not apply", mais plus spécifique:

affected file '%s' is beyond a symbolic link

Hmmm, mount --bindne semble pas fonctionner sur Darwin.

Quelqu'un at-il une astuce qui le fait?

[édité]

OK, j'ai trouvé que la réponse sur Mac OS X est de créer un lien physique. Sauf que cette API n'est pas exposée via ln, vous devez donc utiliser votre propre petit programme pour ce faire. Voici un lien vers ce programme:

Création de liens matériels de répertoire sous Mac OS X

Prendre plaisir!

J'utilise Git 1.5.4.3 et il suit le lien symbolique passé s'il a une barre oblique. Par exemple

# Adds the symlink itself
$ git add symlink

# Follows symlink and adds the denoted directory's contents
$ git add symlink/

La conversion à partir de liens symboliques pourrait être utile. Lien dans un dossier Git au lieu d'un lien symbolique par un script .