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 (fetch) crowbar https://github.com/crowbar/crowbar.git (push) personal https://github.com/jamestyj/crowbar.git (fetch) personal 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 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://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html 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. _______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
