On 2014-10-08 at 04:28:50 +0200, cg wrote: [...]
After cloning ghc repository, I switch every sub-module to Master (it is usually HEAD) branch.
Why are you doing that? :-) [...]
Now after cloning ghc repository, if I don't switch to any branch -- 'git branch' will show all submodules are detached -- the build will succeed.
Well, that's how you're supposed to work with submodules in ghc.git[1]
So why the Master/HEAD branches don't have the latest code?
Generally, the "master" branch refers to the latest upstream code, which is not always supposed to work with GHC HEAD (yet). And if the package is not owned by GHC HQ, you are not allowed to push changes to "master" anyway (as it'd be automatically overwritten by the automatic Git mirror job) Take Cabal for example, we have an automatic mirror-job that keeps Cabal's "master" branch synced to the state of the github.com/ However, we only update the gitlink for Cabal in ghc.git every couple of weeks to Cabal's latest "master" tip commit, as it has the potential to affect performance numbers or simply be temporarily in a broken state wrt GHC HEAD. Then there's Haddock for which it was recently decided to let upstream development progress decoupled from GHC HEAD's API changes, and have GHC HEAD simply use its own branch 'ghc-head' to diverge from upstream until shortly before a GHC release is close (at which point Haddock will converge again). Fwiw, 'git submodule update --remote utils/haddock' will track the "ghc-head" branch in this case. Finally, "binary" is a case where we needed a patch merged into binary, but couldn't wait for the "binary" upstream to merge the pull-request, as it was blocking GHC HEAD development. So that's why we temporarily are on a "ghc-head" branch, which will be switched away from again as soon as "binary"'s upstream "master" branch can be used again with GHC HEAD. And then there's also the potential case when we need to temporarily rollback a submodule update; then we don't necessarily need to 'git revert' commits inside that submodule, but we simply just reset the pointed-to submodule commit to an older commit. I hope this sheds a bit of light on the situation. Then there's also [1] which may provide further pointers. [1]: https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules Cheers, hvr