Беручи до уваги, що 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) та дискусія щодо потенційної підтримки symlink.
Але коментар щодо жорстких посилань стосується Git загалом.
Google "git зберігає жорсткі посилання" і показує, що 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 зберігав жорсткі посилання, то моя стратегія переробки дискового простору не працювала б.