git hard links - знает ли он, что файл является жесткой ссылкой?

Я начал использовать жесткие ссылки вместо символических ссылок для организации файлов ...

Я делал это для фотографий, которые я делаю, чтобы классифицировать их, а также указать, какие из них я хочу напечатать и т. Д.

Я использую git для резервного копирования своих изображений, и кажется, что git думал, что они были новыми файлами, так как размер хранилища вырос до 1 ГБ. Git действительно хорошо распознает переименования, если я не использую git для переименования файла, но он также обрабатывает жесткие ссылки?

Вальтер

Отслеживаемые файлы с несколькими ссылками не приведут к значительному росту хранилища объектов в Git, поскольку каждая ссылка будет представлена ​​одним и тем же объектом BLOB-объекта. Однако ваше рабочее дерево может в конечном итоге расти из-за неработающих ссылок.

Git не отслеживает, являются ли отслеживаемые файлы рабочего дерева жесткими ссылками на один и тот же файл.

Git оставит файлы многосвязных, отслеживаемых, рабочих деревьев в покое, если вы не попросите его сделать что-либо, что повлечет за собой изменение содержимого этих путей или удаление записей каталога путей. Но если вы должны были (например) извлечь старый коммит или ветвь, а затем переключиться обратно на свой обычный, самый последний ветвь / коммит, то Git в конечном итоге «сломает» жесткие ссылки (заменив затронутые пути новыми (но идентичными) ) файлы вместо воссоздания вашей многосвязной ситуации).

Чтобы восстановить ваш многосвязный статус, вы можете написать программу для поиска идентичных файлов и связать их с любым из файлов. Такая операция «повторного связывания» может быть более сложной, если все ссылки не находятся в самом рабочем дереве или, по крайней мере, не в каком-то легко идентифицируемом «внешнем» месте (т.е., вероятно, будет трудно восстановить ссылки, если вы создаете ссылки «Случайные» файлы со всего вашего домашнего каталога в «резервное» хранилище и использование Git для изменения рабочего дерева).

Идея появилась в списке рассылки Git:

• желая Git разорвать ссылки, чтобы клонированные репозитории cp -aбыли независимыми
• предложенныйcore.keepHardLinks (никогда не интегрированный ни в один выпущенный Git?)
• похожий на этот вопрос
• вероятно, другие ...