Моє найкраще буде сценарій оболонки, який замінює символьні посилання копіями, чи є інший спосіб сказати Git слідувати посиланнями?

PS: Я знаю, що це не дуже безпечно, але я хочу це зробити лише в кількох конкретних випадках.

ПРИМІТКА: Ця порада застаріла за коментарем, оскільки Git 1.6.1. Гіт звик поводитись так, і більше не робить.

Git за замовчуванням намагається зберігати посилання, а не виконувати їх (для компактності, і це, як правило, те, що люди хочуть).

Однак мені випадково вдалося змусити його додати файли за межами симпосилання, коли символьне посилання є каталогом.

Тобто:

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

роблячи

 git add /bar/foo/baz

виявилося, що це спрацювало, коли я спробував це. Така поведінка в той час для мене була небажаною, тому я не можу дати тобі інформацію поза цим.

Що я зробив, щоб додати файли в симпосилання в Git (я не використовував, але):

sudo mount --bind SOURCEDIRECTORY TARGETDIRECTORY

Виконайте цю команду в каталогу, керованому Git. TARGETDIRECTORYмає бути створено до SOURCEDIRECTORYвстановлення в нього.

Він добре працює в Linux, але не в OS X! Цей трюк мені допоміг і Subversion. Я використовую його для включення файлів з облікового запису Dropbox, де веб-дизайнер робить свої речі.

Чому б не створити посилання навпаки? Значить замість того, щоб посилатися з репозиторію Git до каталогу додатків, просто зв’яжіть навпаки.

Наприклад, скажімо, я налаштовую програму, встановлену в ~/applicationякій потрібен файл конфігурації config.conf:

• Я додаю config.confдо свого сховища Git, наприклад, в ~/repos/application/config.conf.
• Потім я створюю посилання з символу ~/application, запустивши ln -s ~/repos/application/config.conf.

Цей підхід може не завжди спрацювати, але для мене він працював добре.

Використовуйте натомість жорсткі посилання. Це відрізняється від м'якого (символічного) зв’язку. Усі програми, в тому числі gitбудуть розглядати файл як звичайний файл. Зверніть увагу , що вміст може бути змінена шляхом зміни або джерела або призначення.

На macOS (до 10.13 Висока Сьєрра)

Якщо у вас вже встановлено git та Xcode, встановіть жорстке посилання . Це мікроскопічний інструмент для створення жорстких зв’язків .

Щоб створити жорстке посилання, просто:

hln source destination

оновлення високої Sierra macOS

Чи підтримує каталог файлової системи Apple жорсткі посилання?

Файлова система Apple не підтримує жорсткі посилання каталогів. Усі жорсткі посилання каталогів перетворюються на символічні посилання або псевдоніми, коли ви перетворюєте з форматів томів HFS + в APFS на macOS.

З FAQ щодо APFS на developer.apple.com

Слідкуйте за https://github.com/selkhateeb/hardlink/isissue/31, щоб отримати майбутні варіанти.

На Linux та інших ароматах Unix

lnКоманда може зробити жорсткі посилання:

ln source destination

У Windows (Vista, 7, 8,…)

Хтось запропонував використовувати mklink для створення переходу в Windows, але я не пробував цього:

mklink /j "source" "destination"

Це гачок, що попередньо здійснює заміну, яка замінює крапки символьної посилання в індексі із вмістом цих символьних посилань.

Помістіть це .git/hooks/pre-commitі зробіть його виконуваним:

#!/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

Примітки

Ми максимально використовуємо сумісні з POSIX функціональні можливості; однак diff -aне сумісний з POSIX, можливо, серед іншого.

У цьому коді можуть бути деякі помилки / помилки, хоча він був дещо перевірений.

Увімкнено MacOS(у мене є Mojave / 10.14, gitверсія 2.7.1), використовувати 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>

На це натякали інші коментарі, але в інших відповідях це не було чітко. Сподіваємось, це економить когось деякий час.

Я часто додавав файли поза символьними посиланнями вже досить давно. Це працювало просто чудово, без особливих домовленостей. Оскільки я оновив до Git 1.6.1, це більше не працює.

Можливо, ви зможете перейти на Git 1.6.0, щоб зробити цю роботу. Я сподіваюся, що в майбутній версії Git з'явиться прапор, який git-addдозволить йому знову переходити до посилань.

Я втомився від будь-якого рішення тут або застарілого, або вимагає root, тому я зробив рішення на основі LD_PRELOAD (лише для Linux).

Він вписується у внутрішність Гіта, замінюючи "це симпосилання?" функція, що дозволяє розглядати символьні посилання як їхній вміст. За замовчуванням всі посилання на репо-репо є вкладеними; Детальніше дивіться за посиланням.

Що стосується Git 2.3.2+ (Q1 2015), є ще один випадок, коли Git більше не перейде за символьним посиланням: див. Виконувати e0d201b від Junio ​​C Hamano ( gitster) (головний сервіс Git)

apply: не торкайтеся файлу за символічним посиланням

Оскільки Git відслідковує символічні посилання як символічні посилання, шлях, який має символічне посилання у своїй головній частині (наприклад path/to/dir/file, де path/to/dirє символічне посилання на інше місце, будь то всередині чи поза робочим деревом), ніколи не може з’являтися в патчі, який дійсно застосовується , якщо той же патч спочатку не видаляє символічне посилання, щоб дозволити створювати там каталог.

Виявити та відхилити такий патч.

Так само, коли вхід створює символічне посилання, path/to/dirа потім створює файл path/to/dir/file, нам потрібно позначити його як помилку, фактично не створюючи path/to/dirсимволічне посилання у файловій системі.

Натомість, для будь-якого виправлення у вході, який залишає шлях (тобто не видалення) в результаті, ми перевіряємо всі провідні шляхи до дерева, що виникає, що патч створив би, перевіривши всі виправлення у вхідному, а потім цільовому патчі додаток (або індекс, або робоче дерево).

Таким чином, ми:

• спіймайте помилку або помилку, щоб одночасно додати символічне посилання path/to/dirта файл path/to/dir/file,
• дозволяючи дійсний патч, який видаляє символічний, link path/to/dirа потім додає файл path/to/dir/file.

Це означає, що в такому випадку повідомлення про помилку буде не загальним "%s: patch does not apply", а більш конкретним:

affected file '%s' is beyond a symbolic link

Гмм, mount --bindздається, не працює на Дарвіна.

У когось є хитрість, яка це робить?

[відредаговано]

Гаразд, я знайшов відповідь на Mac OS X - це зробити жорстке посилання. За винятком того, що цей API не відкритий через ln, тому для цього вам потрібно використовувати власну крихітну програму. Ось посилання на цю програму:

Створення жорстких посилань на каталог у Mac OS X

Насолоджуйтесь!

Я використовую Git 1.5.4.3, і він слідкує за пропущеним символьним посиланням, якщо він має кінцеву косу рису. Напр

# Adds the symlink itself
$ git add symlink

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

Перетворення із символьних посилань може бути корисним. Посилання в папку Git замість символьної посилання сценарієм .