GHC Trac Home
Working on GHC
Mailing Lists & IRC
All Feature Req's
Tickets I Created
Patches for review
New Feature Req
Forgot your password?
side by side
lines around each change
White space changes
01/12/11 06:49:45 (
== The perspective on submodules ==
== Submodules ==
Things that work:
* when cloning a new repo, the submodules do point to the right place (the submodules of the parent)
* `git status` shows when a submodule is "dirty" (has local changes or new commits)
* `git diff` shows diffs in submodules too
* `git submodule status` tells you which local submodules have changes (+ at the beginning of the line)
* after `git pull`, you need to do `git submodule update`
* submodules are detached by default, so you must `git checkout master` before you can commit (you don't find out until you push)
* `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.
* 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.
* need to `git submodule init` before you can `git submodule update` in a new tree (or use `git submodule update --init`)
* have to push to submodules before pushing GHC, otherwise other users will not be able to do `git submodule update`.
* 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).
Submodules do not really seem to be designed for what we want to do (work on a cohesive set of components that are developed together): they seem more suited to tracking upstream branches that you do not modify locally.