Игнорировать новые коммиты для подмодуля git

Question

Фон

Использование Git 1.8.1.1 в Linux. Репозиторий выглядит следующим образом:

master
  book

Подмодуль был создан следующим образом:

$ cd /path/to/master
$ git submodule add https://[e-mail]/user/repo.git book

book субмодуль чистый:

$ cd /path/to/master/book/
$ git status
# On branch master
nothing to commit, working directory clean

проблема

Мастер, с другой стороны, показывает, что для подмодуля книги есть "новые коммиты":

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

Git должен полностью игнорировать каталог подмодулей, чтобы мастер также был чист:

$ cd /path/to/master/
$ git status
# On branch master
nothing to commit, working directory clean

Неудачная попытка № 1 - грязный

Внутри файла master/.gitmodules является следующим, согласно этому ответу:

[submodule "book"]
        path = book
        url = https://[e-mail]/user/repo.git
        ignore = dirty

Неудачная попытка № 2 - неотслеживаемая

Изменено master/.gitmodules в соответствии с этим ответом:

[submodule "book"]
        path = book
        url = https://[e-mail]/user/repo.git
        ignore = untracked

Неудачная попытка № 3 - showUntrackedFiles

отредактированный master/.git/config в соответствии с этим ответом:

[status]
   showUntrackedFiles = no

Неудачная попытка № 4 - игнорировать

Добавлен каталог книг в основной файл игнорирования:

$ cd /path/to/master/
$ echo book > .gitignore

Неудачная попытка № 5 - клон

Добавил каталог книг к мастеру следующим образом:

$ cd /path/to/master/
$ rm -rf book
$ git clone https://[e-mail]/user/repo.git book

Вопрос

Как можно book субмодуль находиться в своем собственном каталоге хранилища под master хранилище еще есть мерзавец игнорировать book подмодуль? То есть следующее не должно отображаться:

#
#       modified:   book (new commits)
#

Как подавить это сообщение при выполнении git status в основном хранилище?

Статья о подводных камнях подмодулей в git предполагает, что это неуместное использование подмодулей

Answer 1

Чтобы включить другой репозиторий, который не нужно отслеживать в своем супер-репо, попробуйте это:

$ cd /path/to/master/
$ rm -rf book
$ git clone https://[e-mail]/user/repo.git book
$ git add book
$ echo "book" >> .gitignore

Тогда совершай.

Как указано в статье о подводных камнях в git submodule:

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

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

Когда вы извлекаете другой коммит в подмодуле или делаете новый коммит в нем, супер-репо увидит, что его извлеченный SHA изменился. Вот когда вы получите modified (new commits) линия от git status,

Чтобы устранить это, вы можете:

• git submodule update, который сбросит субмодуль к коммиту, сохраненному в данный момент в супер-репо (подробности см. в git submodule man-страница; или же
• git add book && git commit сохранить новый SHA в супер-репо.

Как уже упоминалось в комментариях, рассмотрите возможность отказаться от book субмодуль: клонировать его внутри супер-репо, если нет необходимости отслеживать его состояние как часть супер-репо.

Answer 2

Просто беги:

$ git submodule update

Это вернет субмодуль к старому коммиту (указанному в parent-repo) без обновления родительского репо последней версией субмодуля.

Answer 3

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

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

modified: book (untracked content)

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

[submodule "book"]
    path = modules/media
    url = https://[e-mail]/user/repo.git
    ignore = dirty

Однако, как только вы внесете эти изменения, родительский репозиторий еще раз примет это к сведению и сообщит о них соответствующим образом:

modified:   book (new commits)

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

[submodule "book"]
    path = book
    url = https://[e-mail]/user/repo.git
    ignore = all

Answer 4

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

В случае ОП:

git config submodule.<name>.active false

См. Коммит 1b614c0, коммит 1f8d711, коммит bb62e0a, коммит 3e7eaed, коммит a086f92 (17 марта 2017 г.) и коммит ee92ab9, коммит 25b31f1, коммит e7849a9, коммит 6dc9f01, коммит 5c2bd8b (16 мар 2017 г.) от Brandon Williams ( mbrandonw )
^{(Объединено Юнио С Хамано -} gitster ^{- в коммите a93dcb0, 30 марта 2017 г.)}

submodule: разделить URL и субмодульный интерес

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

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

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

Для этого введены два варианта конфигурации, submodule.active а также submodule.<name>.active,

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

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

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

Answer 5

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

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

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

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

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

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

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

Answer 6

Бежать

git submodule update 

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