Лучше всего будет сценарий оболочки, который заменяет символические ссылки на копии, или есть другой способ заставить Git следовать символическим ссылкам?

PS: я знаю, что это не очень безопасно, но я хочу сделать это только в нескольких конкретных случаях.

ПРИМЕЧАНИЕ: этот совет устарел согласно комментарию со времен Git 1.6.1. Git обычно так себя ведет и больше не делает.

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, например, at ~/repos/application/config.conf.
• Затем я создаю символическую ссылку ~/application, запустив ln -s ~/repos/application/config.conf.

Этот подход может не всегда работать, но он до сих пор работал хорошо для меня.

Вместо этого используйте жесткие ссылки. Это отличается от мягкой (символической) ссылки. Все программы, в том числе gitбудут обрабатывать файл как обычный файл. Обратите внимание , что содержимое может быть изменена путем изменения либо источника или назначения.

В macOS (до 10.13 High Sierra)

Если у вас уже установлены git и Xcode, установите hardlink . Это микроскопический инструмент для создания жестких ссылок .

Чтобы создать жесткую ссылку, просто:

hln source destination

Обновление macOS High Sierra

Поддерживает ли Apple File System жесткие ссылки на каталоги?

Жесткие ссылки на каталоги не поддерживаются файловой системой Apple. Все жесткие ссылки на каталоги преобразуются в символические ссылки или псевдонимы при преобразовании из форматов томов HFS + в APFS в macOS.

Из часто задаваемых вопросов APFS на developer.apple.com

Следуйте https://github.com/selkhateeb/hardlink/issues/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, переопределяя «это символическая ссылка?» функция, позволяющая обрабатывать символические ссылки как их содержимое. По умолчанию все ссылки на внешние репо являются встроенными; см. ссылку для деталей.

В Git 2.3.2+ (первый квартал 2015 года) есть еще один случай, когда Git больше не будет следовать символической ссылке : см. Commit 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 вместо символической ссылки скриптом .