Использование Git и знание того, когда нужно обновить или зафиксировать подмодуль, который изменился

Question

Я пытаюсь узнать, когда просто git add/git commit подмодуль, или submodule update, когда я вижу (new commits) в моем статусе.

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

Я смотрел .gitmodules чтобы увидеть, что у меня было:

/main$ cat .gitmodules 
[submodule "xm_css/form"]
    path = xm_css/form
    url = https://github.com/HighgateCreative/form.css.git

II. проверил статус в подмодуле:

/main/form$ gs
HEAD detached at 1ce1544
nothing to commit, working directory clean

III. использовал один из двух методов, которые я использую, чтобы присоединить ГОЛОВКУ (хотя после обширного чтения понял, что это не обязательно):

/main/form$ git checkout -b temp
Switched to a new branch 'temp'
bradc@highsite-dev:/var/www/cms/xm_css/form$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 2 commits.
  (use "git push" to publish your local commits)

VI. подтолкнул к началу координат (теперь я понимаю, что это не было бы необходимо, если бы я оставил ГОЛОВУ отсоединен)

/main/form$ git push
Username for 'https://github.com': [e-mail]
Password for 'https://[e-mail]@github.com': 
Counting objects: 10, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (10/10), 790 bytes | 0 bytes/s, done.
Total 10 (delta 4), reused 0 (delta 0)
To https://github.com/HighgateCreative/form.css.git
   1ce1544..272dc7b  master -> master

V. двойная проверка статуса

/form$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

VI. Появление (new commits) во время git status в родительском

/main$ git status
On branch master
Your branch is up-to-date with 'origin/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:   xm_css/form (new commits)

VIIa. Анализ начинается с git diff:

/main$ git diff
diff --git a/xm_css/form b/xm_css/form
index 1ce1544..272dc7b 160000
--- a/xm_css/form
+++ b/xm_css/form
@@ -1 +1 @@
-Subproject commit 1ce1544db293096a740312c4ad5486dd7922085c
+Subproject commit 272dc7baebe70b75da3da00d28ba97b52099ce55

VIIb. Анализ продолжается с git log:

/main/submodule $ git log
commit 272dc7baebe70b75da3da00d28ba97b52099ce55
Author: Brad Cathey 
Date:   Thu Mar 3 12:00:28 2016 -0600

    trying to get buttons to display properly

commit f4141a2ec88de2efb550ec5b14426a54347312b2
Author: Brad Cathey
Date:   Thu Mar 3 10:57:56 2016 -0600

    adding type=button

commit 1ce1544db293096a740312c4ad5486dd7922085c
Author: John smith
Date:   Tue Nov 17 08:39:18 2015 -0600

    Set all 'buttons' to display inline-block

VIIc. Анализ продолжается в субмодуле git diff --submodule=log:

/main$ git diff --submodule=log
Submodule xm_css/form 1ce1544..272dc7b:
  > trying to get buttons to display properly
  > adding type=button

Продумывая все это: SHA не в последовательности (мышление updateб) но > напоследок git diff заставил меня задуматься commitОднако не совсем уверен в --submodule=log вариант.

Мысли?

Answer 1

То, что вы видите в родительском репо, - это gitlink ( специальная запись в индексе), которая записывает новый SHA1 подмодуля.

Каждый раз, когда вы изменяете и фиксируете (и отправляете) содержимое субмодуля, вам также необходимо добавить, зафиксировать и отправить новый SHA1 (gitlink) этого субмодуля из родительского репо.

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

git diff --submodule=log отражает новые коммиты, которые вы сделали внутри самого подмодуля (в то время как родительский репозиторий знает только о новом SHA1, а не о контенте)

Обратите внимание, что с Git 2.11 (4 квартал 2016 года) вы сможете показать фактическую разницу, выполненную в подмодуле из родительского репо.

См. Коммит fd47ae6, коммит 8e6df65, коммит 602a283, коммит 99b43a6, коммит 61cfbc0, коммит 660e113, коммит 8576fde (31 августа 2016 г.) от Jacob Keller ( jacob-keller )
Смотрите коммит cd48dad (31 августа 2016 г.) от Junio ​​C Hamano ( gitster )
^{(Объединено Юнио С Хамано -} gitster ^{- в коммите 305d7f1, 12 сентября 2016 г.)}

" git diff --submodule={short,log} "механизм был улучшен, чтобы позволить" --submodule=diff msgstr "показать патч между коммитами субмодуля, привязанными к суперпроекту.

Остерегайтесь этого последнего варианта, хотя: git diff --submodule=diff в подмодуле, который имеет свои собственные подмодули, которые имеют изменения, выдают ошибку:

fatal: bad object.

Только Git 2.13 (Q2 2017) исправляет эту ошибку:

Смотрите коммит 17b254c (31 марта 2017 г.) Stefan Beller ( stefanbeller )
^{(Объединено Юнио С Хамано -} gitster ^{- в коммите 1776a71, 17 апреля 2017 г.)}

Это происходит потому, что мы неправильно инициализируем среду, в которой запускается diff, в подмодуле.
Это означает, что мы наследуем среду от основного процесса, который устанавливает переменные среды. (Очевидно, мы устанавливаем переменные окружения, которые мы не устанавливаем, когда не в подмодулях, т.е. .git каталог связан)