Commit 039733c1d51503c8bd4afb5cba67d79ba19c6e3e

Authored by Lars Tiede
1 parent 4db3efcc

demo step by step

Showing 1 changed file with 71 additions and 1 deletions   Show diff stats
1   -I'm the parent that uses "git submodule".
  1 +### This is the parent that uses "git submodule".
  2 +
  3 +If you reset your working copy of this repository to the commit right before we added the submodule:
  4 +
  5 +```bash
  6 +git reset --hard 375c69b8e9ffb36b79c0d7cc0121d622c5b169aa
  7 +```
  8 +
  9 +, then this is how you can retrace the demo given at utviklerlunsj:
  10 +
  11 +```bash
  12 +git submodule add my_lib
  13 +git status # shows new metadata file .gitmodules and new *file* my_lib
  14 +git commit -m "[parent_with_submodule] added my_lib submodule"
  15 +```
  16 +
  17 +After committing, we can inspect what git actually did:
  18 +
  19 +```bash
  20 +git show # all changes in last commit, note that git doesn't save the contents of my_lib but rather a reference to a commit SHA
  21 +git cat-file -p HEAD^{tree} # this is (some of) what git actually stored in the last commit. Note the special "type" of my_lib - if it was a file, it would be "blob", if it was a directory, it would be "tree".
  22 +```
  23 +
  24 +You'll find that in the directory 'my\_lib', you are in a different repository:
  25 +
  26 +```bash
  27 +git remote -v # shows that origin is "parent_with_submodule"
  28 +cd my_lib
  29 +git remote -v # shows that origin is "my_lib"
  30 +cd ..
  31 +```
  32 +
  33 +The outputs of 'git log' and 'git status' will differ as well.
  34 +
  35 +Now do some random change in my\_lib and commit it. When you then do a 'git status' in parent, it will show that my\_lib has changed ("new commits"). 'git diff my\_lib' will show the change to the referenced commit SHA.
  36 +
  37 +Now we will deliberately do something awful and commit parent *and push it to origin*.
  38 +
  39 +```bash
  40 +git add my_lib
  41 +git commit -m "new version of my_lib"
  42 +git push
  43 +```
  44 +
  45 +Now what do you think will happen when somebody wants to clone that? Let's try:
  46 +
  47 +```bash
  48 +cd ..
  49 +mkdir temp_clone
  50 +cd temp_clone
  51 +git clone --recursive .
  52 +```
  53 +
  54 +Notice the '--recursive' option? You have to do that in order to not only clone parent, but also all submodules of parent. Yes, you and your users will forget about that constantly. This is the biggest headache with submodules. But there's another. Check this at the end of the output:
  55 +
  56 +```bash
  57 +fatal: reference is not a tree: 5870fc7691231edf23517055b09768e00e123bf7
  58 +Unable to checkout '5870fc7691231edf23517055b09768e00e123bf7' in submodule path 'my_lib'
  59 +```
  60 +
  61 +(Your hash might differ). Git couldn't clone the referenced commit of my\_lib *because it did not find it*. And that is because we did not push (i.e. publish) our changes to my\_lib before we published our changes to parent. **Always push changes to children before you push parent** in order to make sure that the published parent always points to commits of children that are already published..
  62 +
  63 +So here's how we fix this: push the child, then update the submodules in our temporary working copy. Pushing the child is easy, here's how you pull and update submodules in temp\_clone:
  64 +
  65 +```bash
  66 +git submodule update --init --recursive
  67 +```
  68 +
  69 +That command clones submodules if they haven't been cloned yet, and it pulls a new commit when parent's reference has changed. So that command is what you also have to do after every 'git pull' of parent. This is the second big headache with submodules: you have to remember to update the submodules after 'git pull'.
  70 +
  71 +But that's basically it, now you know how submodules work. You can delete temp\_clone now.
... ...