James, thanks for the note on your workflow. I'd like to stick with the ./dev mechanism as much as possible. After a little trial and error with the github.com API I came up with the following curl command which renders markdown for me:
curl --location --request POST --data-binary @<file-to-be-rendered>.md --header "Content-Type: text/plain" https://api.github.com/markdown/raw > <file-to-be-rendered>.html Point a browser at the resulting .html file and see if it looks like it should. Done. Thanks again ... WkH On Sat, Mar 16, 2013 at 2:15 AM, James Tan <ja...@suse.de> wrote: > Hi Ward, > > (CC-ing the list, as it might be useful to others too. Hope you don't > mind!) > > > On 03/16/2013 01:11 AM, Ward Harold wrote: > >> James, looks like Rob beat me to merging the pull request. I liked your >> edits; I learn something new about markdown every day. What do you use to >> render it locally? I want to check my formatting before I add additional >> files. >> >> Thanks again ... WkH >> > > Glad that you like the edits. I actually don't render the Markdown files > locally. I'll describe my complete workflow here, so others can chip in > too and we can improve it collectively. > > I have the main Crowbar repository checked out locally and configured with > `./dev setup`. For example, here's my repo config: > > jamestyj@x200:crowbar(master)> git remote -v > crowbar > https://github.com/crowbar/**crowbar.git<https://github.com/crowbar/crowbar.git> > (fetch) > crowbar > https://github.com/crowbar/**crowbar.git<https://github.com/crowbar/crowbar.git> > (push) > personal > https://github.com/jamestyj/**crowbar.git<https://github.com/jamestyj/crowbar.git>(fetch) > personal > https://github.com/jamestyj/**crowbar.git<https://github.com/jamestyj/crowbar.git>(push) > > When I'm working on the docs or code, I do the following: > > 1) Update local git checkout: > > > git checkout master && ./dev fetch && ./dev sync > > 2) Create branch for my pull request: > > > git checkout -b my-doc-patch > > 3) Start hacking and committing changes locally in logical chunks. For > example: > > > git mv old-file new-file > > vim some-file > ... > > git commit -a -m 'Making things a bit better' > > Committing regularly avoids big commits that are hard to review and > debug. It also makes it easy for me to go back in history if I mess > something up while hacking, or go down the wrong path. > > 4) Push the new commits up to my personal fork: > > > git push personal > > Depending on your git configuration, you may need to explicitly append > the branch name. I have the following in my ~/.gitconfig so I don't > need to: > > [push] > default = current > > I can now view the commits and corresponding changes on the Github, eg.: > > > https://github.com/jamestyj/**crowbar/tree/my-doc-patch<https://github.com/jamestyj/crowbar/tree/my-doc-patch> > > I then navigate to the Markdown file that I want to edit, and then use > Github's nice web UI to edit and preview my changes, committing them > directly from the web UI periodically to avoid losing my changes (eg. > if the browser crashes). > > 5) Once I'm done and happy with all my changes, I usually end up with a > whole bunch of commits, with crappy commit messages. So it's time to > rebase them to reduce noise in the git history and make commits easier > to review and debug. For example: > > > git checkout my-doc-patch && git pull personal my-doc-patch > > git rebase -i HEAD~10 > > This performs an interactive rebase on the last 10 commits, so I can > now squash (and reorder if necessary) commits and give them proper > commit messages. See the following articles for details on interactive > rebase: > > http://git-scm.com/book/en/**Git-Tools-Rewriting-History#** > Changing-Multiple-Commit-**Messages<http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages> > http://gitready.com/advanced/**2009/02/10/squashing-commits-** > with-rebase.html<http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html> > > https://help.github.com/**articles/interactive-rebase<https://help.github.com/articles/interactive-rebase> > > 6) Done with the rebase, I now force push the changes back to my fork: > > > git push -f personal > > WARNING: Be very careful when doing a forced push, and NEVER force push > to main branches in the Crowbar repos (eg. master branch in all > github.com/crowbar/xxx repos). > > 7) I double check my changes on the Github web UI, and then submit a pull > request from there. Make changes and rebase again if necessary. > > Hope this helps! I'll move this to the devguide after collecting comments > and feedback here. > > Cheers, > James T. > -- ... WkH
_______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
