Как удалить git поддерево слияния?

Question

У меня есть проект, который опирается на еще два подпроекта, которые были объединены с использованием стратегии слияния поддеревьев (как описано здесь и там )?

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

По сути, я заметил, что подпроекты перечислены в файле .git / config, поэтому мне интересно, достаточно ли этого, чтобы удалить его оттуда.

После ответа / вопроса Якуба я постараюсь добавить больше деталей к моему вопросу. Проект, над которым я работаю над ProjectA, зависит от библиотеки LibraryB, у которой есть собственный репозиторий git и собственный жизненный цикл. При настройке ProjectA я использовал метод слияния поддеревьев, чтобы добавить зависимость LibraryB (шаги, точно описанные в ссылках, к счастью добавленных VonC). Теперь ProjectA нужны некоторые пользовательские изменения в LibraryB, которые недостаточно универсальны для отправки в репозиторий LibraryB. Итак, я хотел бы отделить LibraryB в ProjectA от его главного репозитория (под разделением я имею в виду, что LibraryB в ProjectA не сможет обновляться из своего главного репозитория и будет отслеживать свою собственную историю только внутри ProjectA).

Подробнее: после проверки моего репозитория ProjectA я выяснил, что единственная ссылка на репозиторий LibraryB находится в файле ProjectA / .git / config в виде:

[remote "gaelib"]
    url = ../libraries/gaelib
    fetch = +refs/heads/*:refs/remotes/gaelib/*

и нет дополнительной информации, связанной с git, в каталоге LibraryB была включена в ProjectA (../libraries/gaelib)

Answer 1

Звучит так, как будто вы хотите "отменить" слияние поддерева и отправить его обратно вверх по течению. Команда git subtree split должна сделать это.

Answer 2

Я не понимаю. Если вы включили libraryB в репозиторий projectA, используя метод слияния поддеревьев, вам не нужно делать никакой развязки. У вас уже есть именно то, что вам нужно:

• Вы можете получить обновления для libraryB из репозитория libraryB. Что, я полагаю, хорошо.

• Вы можете зафиксировать изменения в libraryB внутри репозитория projectA. Эти изменения останутся локальными для этого репозитория, если вы не решите перенести их в другой репозиторий. Они будут частью истории ProjectA и не будут автоматически распространяться в репозиторий libraryB.

В этом весь смысл метода слияния поддеревьев, а не метода субмодулей.

Answer 3

Да, удалите это удаленное указание на libraryB из файла конфигурации. Это предотвратит случайное обновление вашего локального кода с пульта любым лицом, использующим ваше хранилище.

Вам больше ничего не нужно делать - вы просто больше не тянете или не подталкиваете к репозиторию LibraryB.

Answer 4

Если вы хотите сохранить свою собственную версию LibraryB, у вас есть несколько вариантов:

• Вы можете сделать LibraryB неотъемлемой частью вашего проекта: просто удалите или закомментируйте [remote "LibraryB"] раздел в файле конфигурации и внесите изменения в LibraryB внутри вашего проекта.

  Недостатком является то, что будет труднее отправлять патчи для канонической (сторонней) версии LibraryB

• Вы можете продолжить использование слияния «поддерево», но не из канонической версии LibraryB, а из собственного клона (форка) этой библиотеки. Вы должны изменить remote.LibraryB.url, чтобы он указывал на вашу локальную версию, а ваша локальная версия была бы клоном оригинальной LibraryB. Обратите внимание, что вы должны объединить свою собственную ветвь, а не ветвь удаленного отслеживания канонической библиотеки B.

  Недостатком является то, что вам нужно поддерживать отдельный клон и помнить, что ваши собственные изменения (ну, по крайней мере, общие) в LibraryB должны быть сделаны в форке LibraryB, а не непосредственно в ProjectA.

• Возможно, вы захотите перейти от слияния «поддерево», которое переплетает историю ProjectA и LibraryB, к большему разделению, которое может быть достигнуто с помощью субмодуля ( учебник ). В этом случае у вас будет отдельный репозиторий (ветвь) LibraryB, но он будет находиться внутри рабочей области ProjectA; Для фиксации в ProjectA вместо дерева LibraryB в качестве поддерева будет указатель на фиксацию в репозитории LibraryB. Тогда, если вы не хотите следить за разработкой LibraryB, достаточно просто не использовать «git submodule update» (и, возможно, на всякий случай закомментировать или удалить ссылку на каноническую версию LibraryB).

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

  Кроме того, существует также проблема перехода от слияния поддерева к подмодулям. Вы можете либо:

  • Переход от слияния поддерева к подмодулю путем создания репозитория git в поддереве подпроекта в рабочем репозитории суперпроекта (т. Е. «Git init» внутри соответствующего подкаталога + соответствующий «git submodule init» и т. Д.). Это означает, что у вас будет «поддерево» до некоторой исторической точки и субмодуль позже.
  • Переписать историю, используя git filter-branch , чтобы заменить объединение поддеревьев подмодулем. У этого есть недостаток переписывания истории (большой, если кто-то основывал свою работу на текущей истории), и преимущество «чистого начала». Или вы можете немного подождать, пока "git submodule split" (поток в списке рассылки git ) превратится в git ...
    К сожалению Разделение репозитория git в блогах возвращается "host not found"

Я надеюсь, что эта версия решит вашу проблему.

Отказ от ответственности: Я лично не использовал ни слияния поддеревьев, ни подмодулей, ни git-filter-branch.