Web page for Oxford DTC bootcamp and markdown parsing fix

[jonc125]

As well as the page with our installation instructions etc., this also adds a setting to _config.yml which changes the Markdown parser to use, as the default parser doesn't handle nested lists properly.

[ahmadia]

@apawlik - did you check that the change to the default parser in _config.yml didn't break anything? We should probably let pull requests with big changes like this sit open for a little bit longer before merging them in.

Looking at the history of @jonc125's commit, this is a suggested fix for getting github pages working due to an existing bug in maruku, the default MarkDown parser for Hyde (which generates the pages).

I don't know anything about maruku vs. rdiscount as a Markdown parser, but global changes like this should not be made arbitrarily.

[apawlik]

@ahmadia Apologies, my mistake! I read that as a OK'ed fix (rather than suggested by @jonc125). Won't do that again.

[ahmadia]

@wking - I don't know the best way to back this out. The change to _config.yml is in this commit: jonc125@97d06f4

Backing it out will certainly break the oxford-dtc page, but I think that's better than a global unreviewed change to our Markdown parser.

[jonc125]

git-revert is probably the easiest way to back out that commit, although given it wasn't too tidy you might be better off just deleting the offending line from _config.yml until it's been checked on other pages.

[ahmadia]

@jonc125 - Exactly. They do different things to our git history, though, and until Trevor or another git expert is up, I'd prefer to avoid making more changes into master.

@apawlik - This is a very minor issue, so don't sweat it. We're bound to merge in unwanted changes accidentally in the future, and I'd like to take this as an opportunity to have Trevor or another expert walk us through the right procedure for backing them out in the most recommended way.

[wking]

On Tue, May 14, 2013 at 07:07:45AM -0700, ahmadia wrote:

@apawlik - This is a very minor issue, so don't sweat it. We're
bound to merge in unwanted changes accidentally in the future, and
I'd like to take this as an opportunity to have Trevor or another
expert walk us through the right procedure for backing them out in
the most recommended way.

I think opinions will differ here ;). My favorite choices would be:

a. Revert the merge and force push to gh-pages.
b. Add a single commit reverting the _config.yml change.s

Since the merge has been only been public for an hour, I'm leaning
towards (a), but it's a tight race ;).

[ahmadia]

@wking - I am okay with fixing gh-pages with a force-push. Do you want me
to do it?

On Tue, May 14, 2013 at 3:12 PM, W. Trevor King [email protected]:

On Tue, May 14, 2013 at 07:07:45AM -0700, ahmadia wrote:

@apawlik - This is a very minor issue, so don't sweat it. We're
bound to merge in unwanted changes accidentally in the future, and
I'd like to take this as an opportunity to have Trevor or another
expert walk us through the right procedure for backing them out in
the most recommended way.

I think opinions will differ here ;). My favorite choices would be:

a. Revert the merge and force push to gh-pages.
b. Add a single commit reverting the _config.yml change.s

Since the merge has been only been public for an hour, I'm leaning
towards (a), but it's a tight race ;).

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/97#issuecomment-17878362
.

[wking]

On Tue, May 14, 2013 at 07:14:30AM -0700, ahmadia wrote:

@wking - I am okay with fixing gh-pages with a force-push. Do you
want me to do it?

Go ahead.

[apawlik]

@ahmadia Well, today it may be a minor issue but tomorrow I'm going to trash the whole SWC (touch wood). I certainly would like to learn how to recover from situations like this so it's a good lesson (although I didn't intend to make it happen). Thanks for resolving the problem.

[wking]

@jonc125, @apawlik: I'm not sure what your timescale is on this. You
should probably submit an rdiscount change in its own PR. If you
don't want to wait while that gets reviewed, you can push your current
branch to your own repositories and point folks at

http://jonc125.github.io/boot-camps/2013-05-09-oxford-dtc

[ahmadia]

@wking - The boot camp attendees would need a time machine to see it before
the camp, it was last week :)

On Tue, May 14, 2013 at 3:21 PM, W. Trevor King [email protected]:

@jonc125, @apawlik: I'm not sure what your timescale is on this. You
should probably submit an rdiscount change in its own PR. If you
don't want to wait while that gets reviewed, you can push your current
branch to your own repositories and point folks at

http://jonc125.github.io/boot-camps/2013-05-09-oxford-dtc

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/97#issuecomment-17878930
.

[jonc125]

There's no rush for this - I was pointing people at my own page as @ahmadia says! I'll see if I can set up the separate PR shortly.

[wking]

On Tue, May 14, 2013 at 07:17:42AM -0700, Aleksandra Pawlik wrote:

tomorrow I'm going to trash the whole SWC (touch wood).

You have more leeway when it's a boot-camp-specific branch ;). We
don't mind if you want to go crazy on your own ;).

I certainly would like to learn how to recover from situations like
this

You can usually use git reset --hard <commit> to move your branch
top and working tree to a given commit. For example:

$ git merge wking/terrible-branch # Oops!
$ git reset --hard HEAD^ # Recovered :)

It's important to think that sort of thing through though, since it's
easy to make drastic changes in a hurry (although you can almost
always recover with the reflog).

Good reading:

https://www.kernel.org/pub/software/scm/git/docs/user-manual.html#cleaning-up-history
http://git-scm.com/book/en/Git-Branching-Rebasing
http://git-scm.com/book/en/Git-Tools-Revision-Selection#RefLog-Shortnames
http://git-scm.com/docs/git-reset
http://git-scm.com/docs/git-rebase

[ahmadia]

Okay, the commit has been rewound. Thanks for your help Trevor.

git fetch swc
git checkout -t swc/gh-pages
git log # figure out where the merge commit came from
git log --oneline graph # just to double-check
git reset --hard 75f34a464beab76a1fe13dafb64e82870f63c22e # reset local gh-pages
git push -f swc gh-pages:gh-pages # like rm -rf, always think twice before hitting enter with push -f

@jonc125 - It sounds like you've got a plan for putting this pull request back together. Feel free to ping me if you have any questions I can answer.

[apawlik]

@wking Thank you! This is very useful. And thanks @ahmadia for sorting it out.