| | 81 | == Submodules == |
| | 82 | |
| | 83 | Things that work: |
| | 84 | |
| | 85 | * when cloning a new repo, the submodules do point to the right place (the submodules of the parent) |
| | 86 | * `git status` shows when a submodule is "dirty" (has local changes or new commits) |
| | 87 | * `git diff` shows diffs in submodules too |
| | 88 | * `git submodule status` tells you which local submodules have changes (+ at the beginning of the line) |
| | 89 | |
| | 90 | Gotchas: |
| | 91 | |
| | 92 | * after `git pull`, you need to do `git submodule update` |
| | 93 | * submodules are detached by default, so you must `git checkout master` before you can commit (you don't find out until you push) |
| | 94 | * `git submodule update` detaches the local submodules from whatever branch they were on. So if you had done `git checkout master` and committed local changes, the local changes are now invisible (but still stored in the repo). Alternatively, you can use `git submodule update --merge` or `git submodule update --rebase`. Neither seem like a good default. |
| | 95 | * if you had local uncommitted changes in a submodule, then `git submodule update` refuses to update the submodule. Then your repo is in a state where it appears you have a local change to the submodule, this could be confusing. |
| | 96 | * need to `git submodule init` before you can `git submodule update` in a new tree (or use `git submodule update --init`) |
| | 97 | * have to push to submodules before pushing GHC, otherwise other users will not be able to do `git submodule update`. |
| | 98 | * every submodule commit needs to be accompanied by a GHC commit (not clear if this is really a disadvantage, but it's more work and there will be many more commits). |
| | 99 | |
| | 100 | '''Older comments''': |
| | 101 | |
