Зафиксируйте изменения в подмодуле без фиксации родительского репо

Допустим, у меня есть родительский репозиторий myproject и отдельный репозиторий под названием submodule со следующей структурой каталогов:


    root$ find . -not -path *.git*
    .
    ./myproject
    ./myproject/submodule

Теперь я добавляю submodule в качестве подмодуля к myproject.


    root$ cd myproject
    myproject$ git submodule add git://url-to-submodule:submodule.git submodule
    Adding existing repo at 'submodule' to the index

Теперь, допустим, я что-то меняю на submodule.


    myproject$ cd submodule
    submodule$ touch herpin.txt
    submodule$ add herpin.txt
    submodule$ git commit -am "i'm herpin and i'm derpin"

В этот момент я возвращаюсь в родительский репозиторий и проверяю статус git:


    submodule$ cd ..
    myproject$ git status
    # On branch master
    # Changes not staged for commit:
    #   (use "git add ..." to update what will be committed)
    #   (use "git checkout -- ..." to discard changes in working directory)
    #
    #   modified:   submodule (new commits)
    #
    no changes added to commit (use "git add" and/or "git commit -a")

Ну, черт возьми, теперь каждый раз, когда я что-то фиксирую в подмодуле, я также должен коммитить родителя.

Это довольно быстро раздражает, если у вас более сложное дерево подмодулей. Скажем -- 4 уровня в глубину. Если я делаю изменение в самом внутреннем подмодуле, я должен зафиксировать его родителя, его дедушку и бабушку, его прапрародителя и его прапрародителя. Это чертовски боль в ---.

Должен быть лучший способ! (И нет, не вкладывать так много уровней - это не вариант. :/ Это не мой призыв сделать...) Нет ли способа, с помощью которого git-commit может уведомить родительские репозитории о коммите?


person ryanrhee    schedule 06.02.2012    source источник


Ответы (3)


Конечно, вы можете написать для этого свои собственные сценарии. Хуки после фиксации были бы хорошим местом. Но я не уверен, что это то, чего вы хотите, поскольку я думаю, что идея заключалась бы не в том, чтобы реплицировать каждую фиксацию во включающих репозиториях, а в том, чтобы иметь разные уровни абстракций. т.е. сгруппировать серию коммитов в подмодуль в один коммит суперрепозитория, а затем описать изменение менее подробно (подмодуль: реализованная функция x).

person plaugg    schedule 03.03.2012
comment
Для этого не нужны скрипты и хуки. Просто измените каталог на подмодуль, сохраните незафиксированные изменения, потяните ветку, извлеките ветку, вытащите тайник, зафиксируйте незафиксированные изменения, отправьте ветку на удаленный компьютер. Затем из вашего основного места, где вы разрабатываете этот подмодуль, извлеките изменения и перемотайте вперед/слияние. - person KulaGGin; 15.07.2020

Коммит в подмодуль следует рассматривать как коммит в другую внешнюю библиотеку/репозиторий.

Не используйте статус git в корне, используйте его в подмодуле.

Нет, вам не нужно фиксировать изменения в контейнере, вам нужно только фиксировать их из подмодуля.

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

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

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

person Ryan The Leach    schedule 04.05.2018

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

  • Измените каталог на свой подмодуль из вашего корневого проекта. cd submodule.
  • Спрячьте незафиксированные изменения, которые вы внесли в свой подмодуль. git stash
  • Потяните ветку, к которой вы хотите применить свои изменения. git pull <remotename> <branchname>
  • Оформить ветку. git checkout <branchname>
  • Открой тайник. git stash pop
  • Зафиксируйте незафиксированные изменения, как обычно. git add , git commit
  • Отправьте зафиксированные изменения в удаленный репозиторий. git push <remotename> <branchname>.

Теперь вы локально зафиксировали изменения в своем подмодуле и отправили их в удаленный репозиторий. В вашем основном проекте .gitmodules должен быть обновлен и указывать на последнюю фиксацию, которую вы сделали в каталоге вашего подмодуля. Теперь вы можете либо зафиксировать файл .gitmodules для использования фиксации с обновленным подмодулем, либо вы можете отказаться и продолжить использовать старый и не обновленный подмодуль. Но если вы откажетесь и запустите git submodule update --remote, он вытянет эту старую не обновленную ветку, поэтому вы, вероятно, захотите зафиксировать этот файл .gitmodules в своем основном проекте.

Вот глава об этом из книги Pro Git: https://git-scm.com/book/en/v2/Git-Tools-Submodules

person KulaGGin    schedule 15.07.2020