16 comments

[ 4.0 ms ] story [ 52.7 ms ] thread
> I started to get a feeling this wasn't right, and so I googled around for a way to undo the add.

At that moment, the easiest way would have been to "rm -r .git". As git stores all its metadata in that hidden directory, this is a safe way to undo the creation of a repository.

Sorry, but you didn'tblist any benefits, other than teaching you git. What about versioning your articles, distributed backups etc?
There is a simple rule of thumb about unix tools: when you are in need of a -f or --force parameter, most likely something is wrong and you should rethink what you are doing.

Even more so if the tool in question refuses to do anything unless -f is given.

That said, I'm glad to see that the OP took this as a learning experience and not as a reason for posting a long-winded rant about why git should be considered harmful

I'd say rm -f may be the exception - technically you could run a chmod +w before but you'll end up at the same place
On a slightly related note. If anyone is thinking of moving over to Git / Git(hub) backed blogging. Don't count out Github's 'Edit File' ( http://ace.ajax.org/ ) editor online as I constantly find myself amending typo's, etc... Was for sure an added bonus.
I wonder if this was posted more for the "how I blew away my home directory with git" anecdote than anything else.
Title says: "Benefits of a Git-backed Blog"

Blogpost describes: "Deleting all my files with git"

Conspicuously Missing: "Benefits of a Git-backed Blog"

It seems that the benefit of a git-backed blog is that you learn to use git.
I'm just about to switch over from MovableType to GitHub Pages http://pages.github.com/ . They use Jekyll http://jekyllrb.com/ to publish text, HTML or Markdown. So far it's pretty awesome.

The benefits of this particular setup include:

* all articles are under version control

* just do a `push` to publish

* easily run a local Jekyll server to preview articles

* use a real programmer's text editor (not some web form)

* Markdown is the best for tech articles

* write, preview and commit while offline

* code syntax highlighting

* integration of snippets (gists)

* variable layouts for different page types

* pages are static so are served fast

* easy to add comments with Disqus et al

* easily port your content anywhere

* keep images and other binary content alongside text

Which reminds me - dear $DEITY, when is HN going to support Markdown?!

Oh hey, it's the article I expected to read when I clicked on the blog post
Much more complete list than mine, ha. Pelican supports github pages as well, though I decided not to use github in order to learn git better -- which should have been the singular title of the article as it turns out ("benefit") but what the hell, sue me.
* goes to read post *

* comments on it on the blog *

* comes to HN and discovers people have already made my comments in the comment thread *

Great minds...

Perhaps a bit off-topic, but isn't the use of post-receive hooks to publish your content effectively hacking Git to do something that it shouldn't?

For me, the ideal approach was always to use continuous integration to publish/build my site fresh every time I commit.

Not off-topic at all, I'd definitely like to hear more about this. I read a few 'use git to publish a live site' explanations, and settled on the post-receive hook because it was the first one to make sense to me and work, not because it's the ideal way to do it.