#git
#мерзавец
Вопрос:
- Существует ли линейная история фиксации для любого руководителя филиала в репозитории git, вплоть до пустого репозитория git? По сути, список коммитов в его истории, различия которых при применении в порядке могут привести пустое репо к текущему состоянию ветви?
- Есть ли команда «исправление формата git», которая может извлечь эту историю линейных фиксаций
- В частности, эта извлеченная серия исправлений должна использоваться с помощью «git init ; git am patches.txt» чтобы восстановить последнее состояние главы филиала, не сталкиваясь с конфликтами исправлений
Даже если это означает немного написания сценариев для достижения того, чего я хочу выше.
—— Вопрос, заданный изначально ———
У меня есть репо git и я проверил, скажем, филиал branchX
Я хочу сгенерировать последовательность исправлений с помощью «git format-patch», которые я могу использовать для восстановления совершенно нового репозитория git с использованием «git am/apply» с нуля(git init) только с одной веткой и ее полной историей, возвращающейся к нулю.
В настоящее время я попытался получить патч следующим образом из repoA
git --no-pager format-patch --binary --stdout --root branchX gt; patch.list OR # f7ef86f26066fb428305f3809309ba33d70a9feb is considered the zero/empty state/commit of any git repo git --no-pager format-patch --binary --stdout --root f7ef86f26066fb428305f3809309ba33d70a9feb branchX gt; patch.list cd /path/to/repoNew git init git am --3way patch.list OR git am patch.list Но кое-как заплатка.список, созданный приведенной выше командой форматирования-исправления
bash-4.2$ git am --3way /witspace/sarvi/space_sarvi_mynxos/kwaiclean/boot/t Applying: Initial branch reference point created applying to an empty history Applying: Admin created refpoint (likely to handle manual repository mucking) Applying: new-module-makes Applying: new-module-makes Applying: new file for sienna target Applying: change the rule for specifying EXTRA_* Applying: Removing Makefile.am files and modifying copyright entry Applying: changes for bringing up isan-image on maui Applying: Adding group 'routing-sw' to /etc/group. The routing-sw components will be started by sysmgr in process group 'routing-sw'. This will allow us to kill/ restart all routing-sw components without rebooting Linux/SANOS. Applying: added a new dhcpd.conf file that is specific to 13-slot Applying: modify the /etc/dhcpd.conf in each lc-line entry to specifiy the slot number as part of creating DHCP links to correct LCImage Applying: Update build infrastructure for DC3 builds Applying: Use our own passwd/group files instead of using the one in basefs Using index info to reconstruct a base tree... M aci/bootglobalpkg/group .git/rebase-apply/patch:34: new blank line at EOF. warning: 1 line adds whitespace errors. Falling back to patching base and 3-way merge... Auto-merging aci/bootglobalpkg/group Applying: Changes for preparation of new restructure of workspace Applying: DC-OS Codebase Restructure: Stage1 Stage2 for branch sf Using index info to reconstruct a base tree... M aci/bootbios_program/module.mk Falling back to patching base and 3-way merge... Auto-merging aci/bootbios_program/module.mk CONFLICT (content): Merge conflict in aci/bootbios_program/module.mk error: Failed to merge in the changes. Patch failed at 0015 DC-OS Codebase Restructure: Stage1 Stage2 for branch sf hint: Use 'git am --show-current-patch=diff' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". bash-4.2$ Чего я не понимаю, так это того, что если команда «git format-patch», приведенная выше, получает/генерирует все коммиты/исправления из инициализации исходного/исходного репозитория git в правильном порядке, а команда «git am» применяет их только в той же последовательности, почему могут возникнуть конфликты?
Как сделать это правильно ?
Почему невозможно начать с главы ветви, линейно перейти к первому коммиту, привести последовательность исправлений в порядок и применить их в новом репозитории git ветви, чтобы воспроизвести эту линейную историю с помощью исправлений.
Комментарии:
1. Просто дикое предположение: у вас есть файлы с окончаниями строк CRLF вместо LF? Затем вы должны добавить
--keep-crвgit amкоманду.2. попробовал это сделать. кажется, это помогает
3. Фиксации в репозитории Git образуют ориентированный ациклический граф (DAG). Исправление формата является частью DAG, создавая линейное представление, в котором коммиты слияния отбрасываются; непустые коммиты, не связанные со слиянием, преобразуются из моментального снимка и метаданных в текст и различия. Полученные различия образуют чисто линейные цепочки, из которых исходный DAG не может быть восстановлен , поскольку слияния были отброшены.
4. Короче говоря, вы пытаетесь сделать то, что нельзя и не следует пробовать.
5. Если git является DAG, то должна быть возможность перейти от головки ветви к исходному пустому состоянию репозитория git, известному как первая фиксация, тогда почему невозможно в виде последовательности инкрементных фиксаций/изменений получить последовательность различий или исправлений, которые можно использовать для восстановления только этой линейной истории без каких-либо конфликтов ? Мне кажется, это имеет смысл
Ответ №1:
git push path/to/new/repo branchX сделает это, если у вас есть путь к новому репозиторию из старого, или добавит URL-адрес для пути, если он размещен в доступном месте. Иначе
git bundle create my.bundle branchX # get my.bundle to the destination system somehow, then in your new repo git fetch my.bundle branchX Я хочу сгенерировать последовательность исправлений с помощью «git format-patch», которые я могу использовать для восстановления совершенно нового репозитория git с использованием «git am/apply» с нуля(git init) только с одной веткой и ее полной историей, возвращающейся к нулю.
Это неправильный инструмент для этой работы. Как указывает @torek, формат-патч создан для работы с сериями патчей, сообщающими линейную историю.
Комментарии:
1. мы пытаемся объединить 2 разных дерева репо компонентов в одно дерево с 2 подкаталогами compA и CompB в его корне. Для этого мы используем got format-patch —src-prefix=a/compA —prefix=a/CompB для создания линейной серии исправлений из репозиториев compA/ и compA/ git с указанными выше параметрами префикса.Я действительно ищу способ перевести branchX в серию исправлений, которые могут привести к текущему состоянию branchX.
2. для этого были созданы ветвь фильтра и дерево чтения. формат-патча действительно не было. Как вы планировали сопоставить предков, когда у вас две разные нелинейные истории?
3. чтобы было предельно ясно: вы можете делать то, что пытаетесь сделать с помощью Git, просто не так, как вы пытаетесь это сделать. Конечно, если бы у Git уже не было значительно лучших инструментов для выполнения того, что вы хотите, тот, который вы пытаетесь использовать, мог бы быть использован до тех пор, пока его не можно было бы запустить в эксплуатацию, но когда у вас есть отвертка на стене, настойчиво пытаться заставить ваши винты для привода шила просто бессмысленно.
4. Какие инструменты было бы правильно использовать, если бы я хотел сделать следующее 1. возьмите 2 репозитория git compA и CompB, в которых коммиты были сделаны согласованным образом 2. превратите их в 1 репозиторий git с подкаталогами compA/ и CompB/ init 3. Во время процесса я хочу взять эти согласованные коммиты из compA и CompB, которые произошли, и объединить их в одну коммит-версию compA и CompB в новом репозиторииgt; То, что я пытался сгенерировать патчи последовательности с помощью format-patch и «префикса», и применить их из compA и. CompB
5. Нет, это вопросы, основанные на заранее продуманных понятиях, которые было бы очень легко исправить, если бы вы сделали так, как я предлагаю, и разместили анонимные версии, если ваша история такова, чтобы было о чем поговорить конкретно.