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

Параметр --depth 1 в git clone:

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

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

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

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

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

Ответ 1

Обратите внимание, что Git 1.9/2.0 (первый квартал 2014 года) снял это ограничение.
Смотрите коммит 82fba2b от Нгуен Тай pclouds Дуй (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) официально документирует практику получения минимальной истории.
См. Коммит 99487cf, коммит 9cfde9e (30 декабря 2015 г.), коммит 9cfde9e (30 дек. 2015 г.), коммит bac5874 (29 дек. 2015 г.) и коммит 1de2e44 (28 дек. 2015 г.) Стивена П. Смита ('').
^{(Объединено Junio C Hamano - gitster - в коммите 7e3e80a, 20 января 2016 г.)}

Это " Documentation/user-manual.txt "

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

Слияние внутри <<def_shallow_clone,shallow clone>> будет работать, пока база слияния находится в недавней истории.
В противном случае это будет похоже на объединение несвязанных историй и может привести к огромным конфликтам.
Это ограничение может сделать такое хранилище непригодным для использования в рабочих процессах на основе слияния.

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

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

git pull --unshallow историю: git pull --unshallow

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

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

Ответ 2

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

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

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

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

Изменить: для шага 'clone' см. этот ответ