просто запустите:

$ git submodule update

это вернет подмодуль к старой фиксации (указанной в parent-repo), без обновления родительского РЕПО с последней версией подмодуля.

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

первый-это не отслеживаемый контент, который происходит, когда вы вносите изменения в свой подмодуль, но еще не зафиксировали их. Родительский репозиторий замечает это, и git status сообщает об этом соответственно:

modified: book (untracked content)

вы можете подавить их с помощью:

[submodule "book"]
    path = modules/media
    url = https://user@bitbucket.org/user/repo.git
    ignore = dirty

однако после фиксации этих изменений Родительский репозиторий снова обратит на них внимание и сообщит о них соответственно:

modified:   book (new commits)

если вы хотите подавить их, вы должны игнорировать все изменения

[submodule "book"]
    path = book
    url = https://user@bitbucket.org/user/repo.git
    ignore = all

Git 2.13 (Q2 2017) добавит еще один способ включить подмодуль, который не должен отслеживаться его родительским РЕПО.

в случае OP:

git config submodule.<name>.active false

посмотреть совершить 1b614c0, совершить 1f8d711, совершить bb62e0a, совершить 3e7eaed, совершить a086f92 (17 марта 2017), и совершить ee92ab9, совершить 25b31f1, совершить e7849a9, совершить 6dc9f01, совершить 5c2bd8b (16 Mar 2017) by Брэндон Уильямс (mbrandonw).
^{(слитый Junio C Hamano -- gitster -- на совершить a93dcb0, 30 марта 2017)}

submodule: отделить url и интерес подмодуля

на submodule.<name>.url параметр config используется для определения данный подмодуль представляет интерес для пользователя. Это кончится громоздко в мире, где мы хотим иметь разные подмодули проверены в разных worktrees или более обобщенный механизм для выбора какие подмодули представляют интерес.

в будущем с поддержкой рабочего дерева для подмодулей будет несколько рабочие деревья, для каждого из которых может потребоваться только подмножество подмодулей проверенный.
URL-адрес (где можно получить репозиторий подмодулей) не должен отличаться между различными рабочими деревья.

может также быть удобно для потребителей более легко определить группы в составе подмодули, которые их интересуют, в отличие от запуска"git submodule init <path> " на каждом подмодуле, который они хотят проверить в своей работе дерево.

С этой целью вводятся два параметра конфигурации,submodule.active и submodule.<name>.active.

• на submodule.active config содержит pathspec, который указывает, какие подмодули должны существовать в рабочем дереве.
  • в submodule.<name>.active config-это логический флаг, используемый для указания этот конкретный подмодуль должен существовать в рабочем дереве.

важно отметить, что submodule.active функции по-разному чем другие параметры конфигурации, так как он принимает pathspec.
Это позволяет пользователям принимать по крайней мере два новых рабочих процесса:

1. подмодули могут быть сгруппированы с ведущим каталогом, таким образом, что pathspec например'lib/' будет охватывать все библиотека-иш модули, чтобы позволить тем, кто заинтересован в библиотеке-иш модули установить"submodule.active = lib/ " только один раз, чтобы сказать все модули в 'lib/' интересно.
2. как только функция pathspec-attribute изобретена, пользователи могут помечать подмодули атрибутами для их группировки, так что широкий pathspec с требованиями к атрибутам, например':(attr:lib)', можно использовать для того чтобы сказать все модули с '' интересно.
   С , просто нравится the .gitmodules файл, отслеживается суперпроектом, когда подмодуль перемещается в дереве суперпроекта, проект может настроить, какой путь получает атрибут в .gitattributes, так же, как он может настроить, какой путь имеет подмодуль в .gitmodules.

Невик Rehnel ответ будет, безусловно, правильным за то, что вы просите: Я не хотел иметь подмодуль, как, черт возьми, я могу выйти из этой ситуации?!.

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

в вашем случае вы вносите изменения в book репозитории и в какой-то момент зафиксировать эти изменения. Это означает, что у вас есть новые коммиты в этом подмодуле, которые имеют новую ссылку SHA1.

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

cd /path/to/master
git commit . -m "Update 'book' in master"

это обновит ссылку SHA1 в master к самой новой версии доступной в book хранилище. В результате эта фиксация позволяет другим проверять все master & book репозитории на кончике.

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

Run

git submodule update 

на корневом уровне.