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 @.md
--header "Content-Type: text/plain" https://api.github.com/markdown/raw >
.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 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/
