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

281

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

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

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

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

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

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

artfulrobot
источник
13
Здесь была достойная дискуссия о глубине клона
Энди
Да, я бы тоже это прочитал, спасибо Энди. --orphanконцепция кажется похожи , и я намерен иметь люфт. Все еще немного расстроенный, что документы не соответствуют действительности [потому что, кто говорит, что документы --orphanправильны ?!]
artfulrobot
Нашел еще одно отличное обсуждение работы с усеченной историей . Но это не помогает мне.
artfulrobot
1
Git 1.9 (1 квартал 2014 года) полностью поддерживает клонирование мелких репо! Смотрите мой ответ ниже
VonC
1
Git 2.5 (2-й квартал 2015 года) поддерживает фиксацию одной выборки! Я отредактировал свой ответ, ссылаясь на « Извлечь определенный коммит из удаленного репозитория git ».
VonC

Ответы:

305

Обратите внимание, что Git 1.9 / 2.0 (первый квартал 2014 года) снял это ограничение.
Смотрите коммит 82fba2b от Нгуен Тхай Нгук Дуй ( 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 г.). Автор Stephen P. Smith (``) .
(Слиты 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>>будет работать, пока база слияния находится в недавней истории.
В противном случае это будет похоже на объединение несвязанных историй и может привести к огромным конфликтам.
Это ограничение может сделать такое хранилище непригодным для использования в рабочих процессах на основе слияния.

Обновление 2020:

  • В git 2.11.1 введена опция git fetch --shallow-exclude=для предотвращения выборки всей истории.
  • В git 2.11.1 введена опция git fetch --shallow-since=для предотвращения получения старых коммитов.

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


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

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

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

Для того, чтобы заделать часть истории: git fetch --depth=100.

VonC
источник
3
Столько текста, чтобы просто сказать: « Да , если вашей версии git не более 4 лет, а база слияний - в недавней истории»
Борис,
3
@ Борис, этот ответ мне очень помог, так как я скептически относился к использованию мелкого клона. Ранее это иногда ломалось, когда я делаю коммит и сливаюсь. Этот ответ - краткая история, почему он работает сейчас, когда это происходит, и как правильно это сделать.
Яна Агун Сисванто
6

Посмотрите некоторые ответы на мой похожий вопрос " почему-не могу-толкнуть-от-мелкого-клона" и ссылку на недавнюю ветку в списке мерзавцев.

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

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

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

Изменить: для шага «клон» см. Этот ответ

Филип Окли
источник
1
Танки Филиппа. Выборка удаленной ветви все равно будет тянуть за всю историю (AFAIK). Вы правы относительно относительной глубины, на самом деле я хочу какую-то подходящую точку в истории (например, git merge-base 7.x 7.0 в моем случае)
artfulrobot
@artfulrobot: метод --orphan позволяет вам создать короткий узкий «клон» (то есть сфокусированный сегмент), а затем использовать его, как если бы это был правильный репо. Это то, что я еще не пробовал в гневе, но это то, что мне нужно доказать в ближайшее время.
Филипп Окли