Учитывая, что Git не распознает символические ссылки, указывающие за пределами репозитория, есть ли проблемы с использованием жестких ссылок?
Может ли Git их сломать? Не могли бы вы указать мне подробную информацию?
Учитывая, что Git не распознает символические ссылки, указывающие за пределами репозитория, есть ли проблемы с использованием жестких ссылок?
Может ли Git их сломать? Не могли бы вы указать мне подробную информацию?
Ответы:
Объект «дерево», представляющий каталоги в Git, хранит имя файла и (подмножество) разрешений. Он не хранит номер inode (или другой идентификатор файла). Поэтому жесткие ссылки не могут быть представлены в git , по крайней мере, без сторонних инструментов, таких как metastore или git-cache-meta (и я не уверен, возможно ли это даже с этими инструментами).
Git пытается не трогать файлы, которые не нужно обновлять, но вы должны учитывать, что git не пытается сохранить жесткие ссылки, поэтому они могут быть сломаны с помощью git.
О символических ссылках, указывающих за пределами репозитория : у git нет проблем с ними и он должен сохранять содержимое символических ссылок ... но полезность таких ссылок для меня сомнительна, поскольку будут ли эти символические ссылки нарушены или нет, зависит от макета файловой системы вне репозитория git , а не под контролем git.
Я выяснил, что с помощью хуков вы можете зафиксировать git pull
событие (когда есть что вытащить ...), записав обработчик событий скрипта в .git/hooks/post-merge
файл.
Во-первых, вы должны chmod +x
это сделать.
Затем поместите в него ln
команды для воссоздания жестких ссылок при каждом извлечении. Отлично, да!
Это работает, мне это просто нужно для моего проекта и ls -i
показывает, что файлы были автоматически связаны после pull
.
Мой пример .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
ВАЖНО: Как видите, путь к любому файлу в вашем репозитории должен начинаться с $GIT_DIR
, а затем добавить частичный относительный путь к файлу.
Также важно: -f
необходимо, потому что вы воссоздаете файл назначения.
Современный клиент git, кажется, поддерживает символические ссылки и жесткие ссылки внутри репозитория, естественно, даже при отправке в удаленное место и последующем клонировании из него. Однако у меня никогда не было необходимости снова ссылаться на репозиторий git ...
$ mkdir tmp
$ cd tmp
$ git --version
git version 2.24.3 (Apple Git-128)
$ git init .
Initialized empty Git repository in /Users/teixeira/tmp/.git/
$ mkdir x
$ cd x
$ echo 123 > original
$ cat original
123
$ cd ..
$ ln -s x/original symlink
$ cat symlink
123
$ ln x/original hardlink
$ cat hardlink
123
$ git add .
$ git commit -m 'Symlink and hardlink commit'
[master (root-commit) 8df3134] Symlink and hardlink commit
3 files changed, 3 insertions(+)
create mode 100644 hardlink
create mode 120000 symlink
create mode 100644 x/original
$ cd
$ git clone tmp/ teste_tmp
Cloning into 'teste_tmp'...
done.
$ cd teste_tmp/
$ ls
hardlink symlink x
$ cat symlink
123
$ cat hardlink
123
$ cd ~/tmp
$ git remote add origin https://github.com/myUser/myRepo.git
$ git push origin master
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (5/5), 361 bytes | 361.00 KiB/s, done.
Total 5 (delta 0), reused 0 (delta 0)
To https://github.com/myUser/myRepo.git
+ 964dfce...8df3134 master -> master
$ cd ../
$ git clone https://github.com/myUser/myRepo.git
Cloning into 'myRepo'...
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 5 (delta 0), reused 5 (delta 0), pack-reused 0
Unpacking objects: 100% (5/5), done.
$ cd myRepo/
$ cat symlink
123
$ cat hardlink
123
https://github.com/mokacoding/symlinks также указывает на важную вещь: символические ссылки должны определяться относительно.
Из этой проблемы msysgit
Точки соединения не являются символическими ссылками; поэтому символические ссылки просто не поддерживаются в msysGit.
Кроме того, Git никогда не отслеживал жесткие ссылки .
Проблема была ориентирована на Windows (поскольку речь идет о msysgit) и обсуждалась потенциальная поддержка символической ссылки.
Но комментарий о жесткой ссылке касается Git в целом.
Google 'git preserve hard links' показывает, что git не знает, как сохранить жесткую структуру ссылок AFAIK, возможно, намеренно.
В моих веб-проектах используются следующие жесткие ссылки:
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*
Если я хочу внести изменения в index.php, я изменяю его в одном месте, и жесткие ссылки (страницы с описанием продукта) указывают на изменения, за исключением того, что git не сохраняет эту связь во время клонирования и загрузки на других компьютерах.
me@server:www$ git pull
на другой машине создаст новый index.php для каждой жесткой ссылки.
hardlink --ignore-time
на /var/lib/jenkins
, чтобы вернуть часть дискового пространства. В течение дня некоторые файлы снова теряют жесткую связь после git pull
или, mvn compile
но это нормально, я ожидаю, что это произойдет. Если бы git сохранял жесткие ссылки, моя стратегия утилизации дискового пространства не сработала бы.