W dniu 2016-07-24 o 19:34, Jon Forrest pisze: > On 7/24/2016 10:19 AM, Jakub Narębski wrote: > >> As far as I can see you cannot view it online (without downloading). > > True. I changed the way the HTML file is generated so that it > contains all the images downloading it is as good as viewing > it online. I'm not current with the thinking about the merits > of online viewing vs. downloading. Is one more accepted than the other? In my opinion being able to view it online has its advantages. Even casual reader can check it, and point errors or offer suggestions for improvements. > Also, I realized one potentially major disadvantage of sharing in > Google Drive. This is that the URL will change each time I update > the book. Apparently Google is taking away the ability to create > a static link at the end of August 2016. I think you can share a folder instead, and this would be stable. Alternatively, when updating the book you could update the link in the GitHub repository description and/or the README for the fork. > If this book turns out to be popular enough that I have to change it > then I'll have to revisit how to share it. Github Pages looks interesting > but it isn't clear to me how to put this book there since it's written > in AsciiDoc. Well, https://git.github.io/htmldocs/git.html is on GitHub Pages (for a project, that is in https://github.com/git/git.github.io repo that is also used for Git Rev News), and it obviously uses AsciiDoc. You can use Jekyll, or you can just upload HTML, as described in https://help.github.com/articles/creating-project-pages-manually/ (this one is for per-repo GitHub Pages, i.e. using orphan branch gh-pages, not a special named repository like e.g. git.github.io). After each change / release you would need to rebuild HTML version and upload to GitHub pages. This can be automated with hooks. BTW. I thought that Pro Git used Markdown, not AsciiDoc? >> Ah. Could you tell me the summary of those changes? > > There are too many to summarize. Some are of the type that the proofreader > should have caught, and others are my attempt to clarify things. Since I > don't claim to be a Git expert it remains to be seen how successful I am. All right. One issue I have after browsing through changes is that description of changes and their granularity is severely lacking. "A few more very minor changes.", "More piddly changes.", "should have included this in last commit" are not good commit messages. If I find time to comment on changes, I would do that on GitHub, commenting / adding notes on changes there (like the one I posted as demo: https://github.com/nobozo/progit2/commit/43ae203c2ccf1a017153de1b41a8c47eb166dba1#commitcomment-18372006 Best, -- Jakub Narebski author of "Mastering Git" https://www.packtpub.com/application-development/mastering-git http://shop.oreilly.com/product/9781783553754.do https://www.amazon.com/Mastering-Git-Jakub-Narebski/dp/1783553758 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html