Если a git fetch отменяется на полпути, он возобновится?

Иногда выборка любого репозитория git (путем выполнения "git fetch repository_URL" ) может занять много часов в зависимости от размера хранилища и скорости сети.

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

Будет ли он возобновлять выборку, где она остановилась?

Ответы

Ответ 1

Нет, git операции clone/fetch/pull не имеют возможности "возобновить".

Единственная альтернатива упомянутая в этом потоке, gitolite (это perl script управление ACM - уровень контроля доступа для вашего репо, а также предоставление других утилит вокруг доступа git)

gitolite может быть настроен для обновления пакета Git (см. git-bundle manual), который затем может быть загружен через rsync или HTTP, а затем его можно загрузить с помощью клиента rsync HTTP-клиент, который поддерживает возобновление.

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

Недостатки очевидны:

  • Для этого требуется специальная настройка на стороне сервера.
  • Непонятно, что произойдет, если кому-то удастся обновить репозиторий когда кто-то загружает свой пакет, или происходит обновление между смежными попытками загрузки.

Что касается возобновляемой функции git clone/fetch (упоминается в Как завершить клон git для большого проекта при нестабильном подключении? "), есть недавняя дискуссия (март 2016 года) в git список рассылки.

  • Один из подходов состоит в том, что сервер создает пакеты, которые могут быть загружены (с использованием возобновления с помощью wget -c!) и добавлены в локальное репо (поскольку пакет - это один файл, с которого вы можете клонировать, как если бы он был git repo).
    См. "Клонирование Linux из пакета "

То есть:

wget -c https://cdn.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/clone.bundle
git bundle verify clone.bundle
...
clone.bundle is okay
git clone clone.bundle linux
#Now, point the origin to the live git repository and get the latest changes:
cd linux
git remote remove origin
git remote add origin https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git pull origin master

Мы могли бы реализовать возобновляемый клон, сделав немного гибрида интеллектуальный и немой HTTP-протокол.

  1. A git clone в конечном итоге вызывает транспортный уровень и git-remote-curl будет определять URL-адрес info/clone; если ресурс не загружается, все проходит через традиционную кодировку.

  2. Когда git-remote-curl обнаруживает поддержку немого клона, он выполняет "повторите попытку, чтобы успешно загрузить данные пакета полностью" внутренне, предварительно обновляет удаленные ссылки для отслеживания, а затем делает вид, будто его попросили сделать инкрементную выборку. Если это преуспевает без каких-либо die(), все счастливы.

  3. Если вышеприведенный шаг 3. по какой-либо причине должен die() (в том числе нетерпение, поражающее CTRL C), оставьте $GIT_DIR, загрузили файл .info и частично загрузили файл .pack.
    Сообщите пользователю, что клонирование можно возобновить и как.

Обратите внимание, что это для возобновляемого клона, не возобновляемая выборка:

начальный "клон" и последующая инкрементная "выборка" являются ортогональными проблемами.

Поскольку предлагаемое обновление для "клона" имеет гораздо больший выигрыш, чем предлагаемое изменение "выборки", т.е.

  • Количество передаваемых данных намного больше, следовательно вероятность выхода из строя сети в плохой сетевой среде намного выше, потребность в возобновлении намного больше.
  • Не только подход делает "клон" возобновляемым и помогающим клиентов, он помогает серверу выгружать массовую передачу на CDN.

и имеет гораздо меньший урон существующему коду, т.е.

  • Нам не нужно пессимизировать процесс упаковки, только чтобы отказаться большая часть байтов, которые были сгенерированы, как и предлагаемый подход для "выборки".
  • Требуется новый код области, который хорошо изолирован, а переключатель в новый протокол происходит очень рано в обмене без обмена код в существующую кодировку; эти свойства делают его менее рискованным ввести регрессию.

Чтобы избежать использования только HTTP-протокола в новом протоколе, есть предложение для протокола "v2", который позволит обеим сторонам обмениваться возможностями перед рекламой ref. Затем клиент, увидев возобновляемый URL-адрес сервера, знает, следует ли продолжать рекламу.
См. stefanbeller/gitprotocol2-10который подходит для захватов.