Чи безпечно дрібного клонування за допомогою --depth 1, створення команд та повторення оновлень?

--depth 1Варіант в git clone:

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

Але я успішно зробив дрібний клон, вніс деякі зміни і відтіснив ці зміни назад до (голого клону) походження.

Для мене це має сенс - я маю на увазі, чому б і ні? коли клонований ГОЛОВА є ідентифікованим за походженням, і моє зобов'язання виходить за все це, схоже, немає причин. Але керівництво говорить інакше.

Мені подобається думка про мілководний клон - наприклад, про drupal core: немає ніякого способу мені знати, що сталося в drupal 4, коли я починав з 7. - але я не хочу стріляти собі в ногу.

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

Зауважте, що Git 1.9 / 2.0 (1 квартал 2014 р.) Зняв це обмеження.
Див. Комісію 82fba2b , від Nguyễn Thái Ngọc Duy ( pclouds) :

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

Зараз у документації написано :

--depth <depth>::

Створіть "неглибокий" клон з історією, врізаною у вказану кількість змін.

Це походить від комітетів , таких як 0d7d285 , f2c681c та c29a7b8, які підтримують клон, send-pack / accept -pack з / з дрібних клонів.
smart-http тепер також підтримує неглибокий доступ / клонування .

Усі деталі містяться в " shallow.c: 8 кроків для вибору нових комісій для.git/shallow ".

Оновлення червня 2015 року: Git 2.5 навіть дозволить отримати єдиний комітет !
(Кінцевий неглибокий корпус)

Оновлення січень 2016: Git 2.8 (Mach 2016) тепер офіційно документує практику отримання мінімальної історії.
Див. Команду 99487cf , фіксує 9cfde9e (30 грудня 2015 р.), Фіксує 9cfde9e (30 грудня 2015 р.), Виконує bac5874 (29 грудня 2015 р.) Та виконує 1de2e44 (28 грудня 2015 р.) Стівена П. Сміта (``) .
^{(Об’єднав Хуніо С Хамано - gitster- у комітеті 7e3e80a , 20 січня 2016 р.)}

Це " Documentation/user-manual.txt"

A <<def_shallow_clone,shallow clone>>створюється шляхом вказівкиgit-clone --depth перемикача.
Пізніше глибину можна змінити за допомогою git-fetch --depthперемикача або відновити повну історію за допомогою--unshallow .

Об’єднання всередині завіту <<def_shallow_clone,shallow clone>>буде працювати до тих пір, поки в останній історії є база злиття.
В іншому випадку це буде як злиття споріднених історій і може призвести до величезних конфліктів.
Це обмеження може зробити такий сховище непридатним для використання у робочих процесах на основі злиття.

Оновлення 2020:

• git 2.11.1 введена опція, git fetch --shallow-exclude=щоб запобігти вилученню всієї історії
• git 2.11.1 введена опція git fetch --shallow-since=для запобігання отримання старих комітетів.

Докладніше про процес оновлення дрібного клону див. У розділі " Як оновити дрібний клон git? ".

Як коментує Річард Майкл :

для заповнення історії: git pull --unshallow

І Olle Härstedt додає в коментарях :

Для того, щоб закрити частину історії: git fetch --depth=100.

Дивіться деякі відповіді на моє схоже запитання, чому-cant-i-push-from-a-shallow-clone, та посилання на останній потік у списку git.

Зрештою, вимірювання «глибини» не відповідає між репостами, оскільки вони вимірюють їхні окремі ГОЛОВІ, а не (а) голову, або (б) комісію, яку ви клонували / дістали, або (в) щось інше ви мали на увазі

Важкий біт - це правильний випадок використання (тобто невідповідний), так що розповсюджені, а отже, ймовірно розбіжні репозиції все ще працюватимуть щасливо разом.

Схоже, це checkout --orphanправильний етап "налаштування", але все ще не вистачає чітких (тобто простої зрозумілої однорядкової команди) інструкцій щодо кроку "клонування". Скоріше це виглядає так, що вам потрібно initзробити репо, встановити remoteгілку відстеження (ви хочете лише одну гілку?), А потім fetchту єдину гілку, яка відчуває себе довго завитою з більшою можливістю помилок.

Редагувати: Для кроку "клонування" дивіться цю відповідь