Як оновити клон git --mirror?

144

Я створив репозиторій git для відображення живого сайту (який є не голим сховищем git):

git clone --mirror ssh://user@example.com/path/to/repo

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

Мені б хотілося постійно оновлювати все: комісії, довідки, гачки, гілки тощо.

Дякую!

— Дж. Бруні
джерело

Відповіді:

213

Це команда, яку потрібно виконати на дзеркалі:

git remote update

— ralphtheninja
джерело

@Magnus Skog: Чудово. Дякую! Це все? Чи потрібна мені ще одна команда, наприклад git fetch? Або git remote updateпоодинці все це вдасться зробити?

— Дж. Бруні

Я також хотів би знати, в чому різниця для отримання git.

— Thorbjørn Ravn Andersen

@ Thorbjörn (вам доведеться робити шведську ö :)): Git fetch просто оновлює ваш сховище з віддаленими посиланнями з віддаленого. Ця команда оновлює все у дзеркальному сховищі.

— ralphtheninja

Ось хороший відповідь , який пояснює більше: stackoverflow.com/questions/3959924 / ...

— ralphtheninja

'git remote update --prune' зробить усе це, але видалить гілки, коли вони будуть видалені з оригінального сховища.

— teeks99

Щодо комітетів, рефрижерацій, гілок та " et cetera ", відповідь Магнуса просто працює ( git remote update).

Але, на жаль, немає способу clone/ дзеркала / update гачки , як я хотів ...

Я знайшов цю дуже цікаву нитку про клонування / дзеркальне відображення гачків:

http://kerneltrap.org/mailarchive/git/2007/8/28/256180/thread

Я вивчив:

Гачки не вважаються частиною вмісту сховища.
Є більше даних, як-от .git/descriptionпапка, яка не клонується, як і гачки.
Гачки за замовчуванням, які з’являються в режимі, hooksпоходять відTEMPLATE_DIR
Є ця цікава templateособливість на git.

Таким чином, я можу або проігнорувати цю "річ клонування гаків", або піти на rsyncстратегію, враховуючи цілі дзеркала (резервне копіювання + джерело лише для інших клонів).

Ну ... я просто забуду про клонування гачків і дотримуюся git remote updateшляху.

Sehe тільки що зазначив, що не тільки "гачками" не керується clone/ updateпроцесом, а й сховищами, перезаписуванням тощо. Отже, для суворого резервного копіювання, rsyncабо еквівалента, це справді шлях. Оскільки це в моєму випадку насправді не потрібно (я можу дозволити собі не мати гачків, сховищ тощо), як я вже сказав, я буду дотримуватися цього remote update.

Дякую! Трохи покращив власне "git-fu" ... :-)

— Дж. Бруні
джерело

Дивіться тут: Git не клонує всі гілки на наступних клонах?

Якщо ви дійсно хочете цього, потягнувши гілки замість push --mirror, ви можете подивитися тут:

"fetch --all" у гострому сховищі git не синхронізує локальні гілки з віддаленими

Ця відповідь надає детальні кроки щодо того, як цього досягти відносно легко:

— sehe
джерело

pushне є для мене варіантом, тому що мені потрібно це зробити у приймальній стороні (звідки знаходиться клон); pullтакож не є варіантом, тому що дзеркальне сховище - це голий сховище (жодне робоче дерево, таким чином, жодне "потягнення") - здається, що git remote updateсправді це все робиться (набагато простіше, ніж відповідь на посилання) ... У будь-якому випадку, дякую! Звичайно, у пов'язаних питаннях / відповідях є цінна інформація.

— Дж. Бруні

гаразд, я мав на увазі тягнути, як у звичайній мові. Технологія натискання та витягування. Навряд чи є інше слово, окрім безглуздого: “отримуйте дані з віддаленого пристрою активно у клієнта”, яке б не дублювало слово, яке має значення для git чи DVCS-систем :) На другому посиланні ви знайдете потрібну інформацію. Зауважте, що "віддалене оновлення git" насправді не підтримує статус "дзеркала" без додаткових операцій, згаданих там

— 11:00

хм ... вибачте (HTH) - здається, "абсолютне" дзеркало легше досягти за допомогою простої "rsync" оригінальної папки repo ... не те, що я хотів, але .. я просто зробив кілька тестів ... і ніби нічого не копіює гачки - що мене особливо цікавить ...

— Дж. Бруні

FYI, цілі цього дзеркала є лише такими: 1) повне резервне копіювання, звідки я можу відновити, якщо дані на оригінальному сервері repo втрачені; 2) десь звідки інші можуть клонуватись та отримувати місцеве робоче репо, не маючи доступу до оригінального джерела репо

— J. Bruni

Якщо ви хочете гачки і все, гитоз може (не пам’ятаю добре) те, що вам потрібно, але я б rsyncу цьому випадку пішов . Крім того, я припускаю, що ви забуваєте про сховища (див. Тут ) і також переносите інформацію ...?

— sehe