Получение патча Git для всех коммитов всех ветвей удаленного репозитория

Я немного запутался в том, как Git обрабатывает начальный git clone удаленного репозитория. Мне нужно получить полный патч Git (diff) для всех коммитов во всех ветках для заданного <repo> URI.

В настоящее время я делаю следующее:

$ git clone <repo>
$ git rev-list --all | xargs git show

Тогда меня беспокоит: получает ли Git все данные репозитория в своем индексе (включая все коммиты из всех веток) или он получает полную историю только для главной ветки?

Другими словами, мой вопрос: достаточно ли одного git clone для получения "полного" патча/диффа, который мне нужен?

ОБНОВЛЕНИЕ: <repo> может иметь несколько веток-сирот


person ddnomad    schedule 05.09.2018    source источник


Ответы (2)


git clone предполагается копировать весь репозиторий со всеми ветками.

Попробуйте клонировать его, а затем запустите git branch -a. В нем должны быть указаны все филиалы.

person Shayki Abramczyk    schedule 05.09.2018
comment
Ну, меня больше всего беспокоило, действительно ли клонирование извлекает все изменения из первоначальной фиксации во всех ветвях. Список удаленных филиалов сам по себе не является подтверждением. Хотя прямо сейчас я почти уверен, что это так (спасибо stackoverflow.com/questions/16427600/). Тем не менее, я был бы очень признателен за ссылку на соответствующий документ, в котором это прямо указано. - person ddnomad; 05.09.2018
comment
@ddnomad: На самом деле, список удаленных веток является довольно хорошим подтверждением, потому что git не может хранить ссылку без сохранения (по крайней мере, части) соответствующей истории. Возможна неглубокая история ссылки — в этом случае последняя фиксация, показанная в истории этой ссылки, будет иметь родительскую запись. Но если вы специально не запрашивали неглубокую историю, то это произошло бы только в том случае, если история на удаленном компьютере уже была неглубокой. - person Mark Adelsberger; 05.09.2018

Обновление. В комментариях к другому ответу вы запросили документацию о поведении git. Это будут git clone документы (https://git-scm.com/docs/git-clone ). Если это то, о чем вы на самом деле просили, вы должны были сказать об этом в своем вопросе, а не хоронить настоящий вопрос в комментарии. Тем не менее, имейте в виду, что запросы на документацию не относятся к теме, и если вам нужны документы git, их довольно легко найти, погуглив соответствующую команду.


получает ли Git все данные репозитория в своем индексе (включая все коммиты из всех веток) или он получает полную историю только для главной ветки?

Хорошо...

Что касается того, что вы пытаетесь спросить, по умолчанию clone копирует полную историю всех веток. Вы можете ограничить это поведение с помощью таких параметров, как single-branch или depth, но по умолчанию используется копирование всего.

Тем не менее, ваша терминология немного проблематична. index обычно представляет собой один снимок проекта, представляющий содержимое в том виде, в каком оно было бы записано git commit. (Исключением является слияние, когда может храниться несколько состояний конфликтующих файлов.) Это не то место, где хранится история, и это не то, к чему обращается rev-list.

Таким образом, git не «получает все данные репозитория в свой индекс»; он получает данные в локальной базе данных.

Кроме того, помимо истории всех ветвей может быть дополнительная информация, которая не загружается по умолчанию. А вот если вопрос именно о ветках и их историях, то да, все навскидку.

person Mark Adelsberger    schedule 05.09.2018
comment
Цените ваши замечания по терминологии. Есть ли более или менее краткая документация (или другой ресурс), где я могу разобраться в деталях? - person ddnomad; 05.09.2018
comment
git-scm.com/docs/git-clone — это скорее CLI варианты и немного о внутренней работе. Но все равно спасибо, попробую сам найти документы в локальной базе данных Git. - person ddnomad; 05.09.2018
comment
@ddnomad - Документация, которую вы запросили в то время, когда я писал это обновление, касалась того, что извлекается клоном, так что это то, что я предоставил. Я не знаю краткого документа о внутренней работе git, так как это довольно широкая тема. - person Mark Adelsberger; 05.09.2018