Безопасно ли очищать клон с помощью --depth 1, создавать коммиты и снова получать обновления?

Question

Опция --depth 1 в git clone:

Создайте неглубокий клон с историей, усеченной до указанного количества ревизий. У мелкого репозитория есть ряд ограничений (вы не можете клонировать или извлекать из него, ни выдвигать из него, ни в него), но этого достаточно, если вас интересует только недавняя история большого проекта с длинной историей, и вы хотите отправить исправления в виде исправлений.

Но я успешно сделал мелкий клон, совершил некоторые изменения и отодвинул эти изменения обратно к источнику (голый клон).

Это имеет смысл для меня - я имею в виду, почему нет? когда клонированная ГОЛОВА идентифицируется в источнике, и мой коммит приходит поверх этого, кажется, нет никакой причины. Но в руководстве сказано иначе.

Мне нравится идея мелкого клона - например, Ядра друпалов: мне никак не нужно знать, что происходило в друпале 4, когда я начал с 7. - но я не хочу стрелять себе в ногу.

Так безопасно ли обрабатывать клон, разрабатывать коммиты в нем, тянуть снова, чтобы не отставать от обновлений от источника?

Answer 1

Обратите внимание, что в Git 1.9 / 2.0 (первый квартал 2014 года) снято это ограничение.
См. commit 82fba2b , из Nguyễn Thái Ngọc Duy (pclouds):

Теперь, когда git поддерживает передачу данных от или к мелкому клону, эти ограничения больше не выполняются.

Документация теперь читается :

--depth <depth>::

Создать «неглубокий» клон с историей, укороченной до указанного количества ревизий.

Это вытекает из коммитов типа 0d7d285, f2c681c и c29a7b8 , которые поддерживают клон, send-pack / receive-pack с / от мелких клонов.
smart-http теперь поддерживает мелкую выборку/ тоже клон .

Все подробности в "shallow.c: 8 шагов для выбора новых коммитов для .git/shallow".

Обновление июнь2015: Git 2.5 даже позволяет извлекать один коммит !
(абсолютный мелкий регистр)

---

Обновление январь 2016:Git 2.8 (Mach 2016) теперь официально документирует практику получения минимальной истории.
См. commit 99487cf , commit 9cfde9e (30 декабря 2015), commit 9cfde9e (30 декабря 2015 г.), коммит bac5874 (29 дек. 2015 г.) и коммит 1de2e44 (28 дек. 2015 г.) Стивен П. Смит (``) .
^{(Объединено с Junio ​​C Hamano - 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>> будет работать до тех пор, пока база слияния находится в недавней истории.
В противном случае это будет похоже на объединение несвязанных историй и может привести к огромным конфликтам.
Это ограничение может сделать такое хранилище неподходящим для использования в рабочих процессах на основе слияния.

---

Подробнее о процессе обновления мелкого клона см. " Как обновить мерзкий клон git? ".

---

Как прокомментировал Ричард Майкл :

для истории обратной засыпки: git pull --unshallow

И Олле Харстедт добавляет в комментарии :

Для обратной засыпки часть истории: git fetch --depth=100.

Answer 2

См. Некоторые ответы на мой похожий вопрос why-cant-i-push-from-a-shallow-clone и ссылку на недавнюю ветку в списке git.

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

Сложным является правильное определение варианта использования (то есть самосогласованного), так что распределенные и, следовательно, расходящиеся репо будут по-прежнему счастливо работать вместе.

Похоже, что checkout --orphan является правильным этапом «настройки», но все еще не хватает четкого (т. Е. Простой понятной однострочной команды) руководства по этапу «клонирования». Скорее всего, вам нужно init репо, настроить remote отслеживающую ветвь (вам нужна только одна ветвь?), А затем fetch эту единственную ветвь, которая кажется долгой, растянутой с большим количеством ошибок. ,

Редактировать: шаг "клон" см. этот ответ