Updating Haddock submodule

[Simon Peyton Jones]

| 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 at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs