| Is | https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules | #MakingchangestoGHCsubmodules | what you are looking for? Yes, it's the right kind of thing. I failed to find that, apologies. But - the page is advertised as work in progress - it checks out 'master'. Is that always right? perhaps not (see my comments) - it assumes you have anticipated the need for change before you do them Much more likely is my situation in which I altered my tree and then thought "oh now I have to commit" - it's at the bottom of a long page, most of which is irrelevant if you use ./sync-all (I think??) More generally I think I just need a bit more hand-holding for this process. Examples of expected output at the various stages would be useful. (I didn't include those in my writeup, but I should have.) | Basically in step 12, you do your GHC hacking. Git should also show you | a one line change with a commit reference which is your updated | Haddock. | You should commit that as well. There's an example of the need for an example. How does it display that one line change? What command makes it do so. | Not sure why you have step 14, it seems to me that you should be good | after 13. At step 14 you will already be pointing to the appropriate | commit, it will just happen to be the same as the master branch at that | point too so I think you're done. OK. But the current page clearly states that submodules should be in a detatched-head state, and it plainly isn't at that moment. Perhaps that's fine, but an unequivaocal statement that it's fine would be super helpful. I'm *not* complaining -- just trying to articulate explicitly what would be helpful to me (or other ill-informed people) next time. Thanks SImon | | -- | Mateusz K. | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs