Using Git and knowing when to update or commit a submodule that has changed

Question

I'm trying to learn when to simply git add/git commit a submodule, or submodule update, when I see (new commits) in my status.

Note: I'm okay to have the final version of the /form submodule as part of the parent, i.e., I'm comfortable integrating the entirety of the current status of the submodule into the parent, if that helps to know.

I. viewed .gitmodules to see what I had:

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

II. checked the status in the submodule:

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

III. used one of two methods I use to reattach the HEAD (although after extensive reading, realized this is not necessary):

/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. pushed to the origin (now I realize this would not have been necessary if I would have left the HEAD detached)

/main/form$ git push
Username for 'https://github.com': myemail@gmail.com
Password for 'https://myemail@gmail.com@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. double check status

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

VI. The appearance of (new commits) during a git status in the parent

/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. The analysis begins with 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. The analysis continues with 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. The analysis continues in submodule 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

Thinking through all this: a. The SHA's are not in sequence (thinking update) b. but the > in the last git diff has me thinking commit, however not completely sure of the --submodule=log option.

Thoughts?

score 0 · Answer 1 · edited May 23 '17 at 12:09

What you see in the parent repo is the gitlink (a special entry in the index) which records the new SHA1 of the submodule.

Each time you modify and commit (and push) a submodule content, you need to add, commit and push the new SHA1 (gitlink) of that submodule from the parent repo as well.

That SHA1 does not have to be in sequence: it simply reflects what commit you chose to checkout the submodule with.

git diff --submodule=log reflects the new commits you have done within the submodule itself (while the parent repo only knows about the new SHA1, not about the content)

Note, with Git 2.11 (Q4 2016), you will be able to show the actual diff done within the submodule from the parent repo.

See commit fd47ae6, commit 8e6df65, commit 602a283, commit 99b43a6, commit 61cfbc0, commit 660e113, commit 8576fde (31 Aug 2016) by Jacob Keller (jacob-keller).
See commit cd48dad (31 Aug 2016) by Junio C Hamano (gitster).
^{(Merged by Junio C Hamano -- gitster -- in commit 305d7f1, 12 Sep 2016)}

The "git diff --submodule={short,log}" mechanism has been enhanced to allow "--submodule=diff" to show the patch between the submodule commits bound to the superproject.

Beware of that last option though: Running git diff --submodule=diff in a submodule which has it's own submodules that have changes get the error:

fatal: bad object.

Only Git 2.13 (Q2 2017) fixes that bug:

See commit 17b254c (31 Mar 2017) by Stefan Beller (stefanbeller).
^{(Merged by Junio C Hamano -- gitster -- in commit 1776a71, 17 Apr 2017)}

This happens, because we do not properly initialize the environment in which the diff is run in the submodule.
That means we inherit the environment from the main process, which sets environment variables. (Apparently we do set environment variables which we do not set when not in a submodules, i.e. the .git directory is linked)

Using Git and knowing when to update or commit a submodule that has changed

1 Answers1