Как сделать резервную копию репозитория, созданного с помощью жестких ссылок - PullRequest
0 голосов
/ 27 декабря 2010

Мы создали git bare в режиме совместного использования и создали хранилище данных, клонировав git bare.

Поскольку и репозиторий git bare, и репозиторий git находятся в одной файловой системе, кажется, что объектные файлы жестко связаны для экономии места.

Я хотел сделать резервную копию репозитория git bare и удалить его.хранилище данных.

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

Есть ли способ скопировать все объектные файлы изхранилище данных, которое жестко связано с пустым хранилищем, чтобы я мог удалить хранилище данных и создать резервную копию хранилища?

Ваша помощь очень ценится.

1 Ответ

3 голосов
/ 08 января 2011

Не бойся.Вы можете просто удалить одну из копий, не теряя другую.Существует не один «оригинал», а один «экземпляр».Вместо этого оба являются «оригинальными» файлами, которые будут существовать без другой стороны.Только содержимое файла передается на диск и, таким образом, сохраняется только один раз.

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

Конечно, поскольку содержимое файласохраняются на диске только один раз, обе копии будут изменены, если вы отредактируете одну из них.Но это не проблема.Git никогда _changes_ файлов в базе данных объектов, если только добавляет их (и иногда удаляет (= отменяет связь) их при сборке мусора).Поскольку объектные файлы в Git являются неизменяемыми, тот факт, что они жестко связаны с другими неизменяемыми файлами, вообще не имеет значения (кроме экономии места на диске), поэтому опция -l теперь используется по умолчанию в git-clone.

...