
| Maybe we need different two different presentations. One concise | reference-like wiki page for Git-gnostic devs, and one for `./sync- | all`-accustomed devs (or maybe even a rosetta-stone like translation | between 'sync-all' invocations, and what the respective Git-only | commands look like) Maybe so. But we *certainly* need the one for people who are not Git-gnostic. WE provide sync-all, and advise its use for most folk, precisely because it automates a number of tricky corners. So our primary Git-un-gnostic documentation should be directed at that workflow. By all means there can be more implementation detail behind it, for Git gurus. I'm begging for it. Begging! Humbly! Simon | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | Sent: 17 July 2014 09:20 | To: Simon Peyton Jones | Cc: Mateusz Kowalczyk; ghc-devs@haskell.org | Subject: Re: Updating Haddock submodule | | On 2014-07-17 at 08:54:32 +0200, Simon Peyton Jones wrote: | | [...] | | > - it's at the bottom of a long page, most of which is irrelevant if | > you use ./sync-all (I think??) | | Fwiw, the page was written to be a `./sync-all`-agnostic on purpose (in | fact, ./sync-all isn't mentioned only once for pre-submodule trees) | | [...] | | > I'm *not* complaining -- just trying to articulate explicitly what | > would be helpful to me (or other ill-informed people) next time. | | Maybe we need different two different presentations. One concise | reference-like wiki page for Git-gnostic devs, and one for `./sync- | all`-accustomed devs (or maybe even a rosetta-stone like translation | between 'sync-all' invocations, and what the respective Git-only | commands look like) | | Fwiw, I have started experimenting with a `runghc`-based ./sync-all | replacement[1] (which uses only the packages bundled with GHC), but I | don't have time to work on it for the next couple of weeks. | | | Cheers, | hvr | | [1]: Currently, it's more of a ghc.git advisor, checking the current | state of your Git repo, and telling you what commands you should | invoke next, but it's in its really earliest stages. If anyone | wants to pick it up, and work on it, lemme know.