Setting up your own blog

I guess I'm one of those 'very few', because every GUI and frontend I've used that tries to hide what's going on underneath has been far more cumbersome to use than the command line.

The only thing I'll use a Git GUI for is to check the history/revision graph.

For the first 6 months I used git, which was because I started a new job where it was used, I stuck almost exclusively to a coworker's wiki page, "<name>'s git cheatsheet". I remember re-cloning the repo so many times when chances are there was a way I could have fixed the mess I'd created.

I didn't know what I was doing and it was very complicated. It had a steep learning curve.

Now, some six years later, I still only use a handful of commands regularly, but really, aside from the painful-to-read man pages (they are very clear, but contain so many flags and other tidbits), I find it very simple to understand and to use. I rarely ever get confused. I'm not a big fan of `rebase` but I can see where it would have its purpose in merging feature branches back to the trunk/master (and if I can find a coworker using it in a nice, clear way, I might adopt it myself). I never use `--force` and recommend that everyone everywhere avoid it once they've pushed.

But really, and there may be some "survivor bias" involved here, I think it's a very well done system for what it does, and I am generally able to reason pretty clearly about what's going on and help others figure out what their issues are. It's quite possible that bzr/hg/darcs is a better and cleaner way of doing the same tasks, and I still have no idea about many commands and I am sure there are things that I have glossed over thinking that I understand them... but it makes sense to me; I don't like any of the GUIs (though I tend to like to "live" in the terminal as much as possible, I've seen things I don't like in both Tower and Sourcetree), and it just seems right to me.

Sorry to go off on a tangent there...

I'd be interested to know where you get these numbers, as this doesn't match my observations at all. I generally see people move quite quickly from a GUI to the command line.

Do you use linux? (If not, that would explain it) Do you claim the same thing for all the other gnu tools (grep et al)?

Git might have some esoteric flags and commands at some points but is not ugly at all and, when understood, it really feels beautiful (and safe, oh so safe to use knowing I know how to recover from practically anything, git has my back).

edit: looking at your other response... using Windows devs who are unfamiliar with GUIs as a metric is not really a good point. If you're going to use Argumentum ad populum then bad programming practices are better than good practices.

I have used git on the command line since day 1. It really isn't that hard.

We use version control because sometime we mess up, so we want to go back in the past and compare values of the same file at different points in time. I don't understand how this kind of problem ever arises when you have a blog: You never need to compare multiple versions of the same post, and if you use files, you always use a different file for each post.

We also use version control when we want to have parallel development (ie keep a stable, working master branch, and toy around in a dev branch). When you have a blog, you just use a _drafts folder that is configured so that what is inside is never published; when your post is ready you move it to the _public folder or whatever. Another worthless feature in that use case.

What _is_ useful from a version control, and more specifically from git, is its ability to replicate everywhere: push to your personal backup, push to github, ush to your webserver. It is used both as a backup and as a way to have your content be where you distribute files. But git is not the only option availale to sync content, and far from the only one. A HTTP POST is more common, and a Dropbox sync is even easier (you don't have anything to do, and the content is automatically synced and distributed for free by Dropbox)

0. http://blog.getpelican.com/

My first post about Hugo on my (obviously) Hugo-powered site: https://npf.io/2014/08/hugo-is-awesome/

edit: disregard me. I was busy being a bad user who doesn't read

You could easily argue those other services don't give "complete" control either.

With Jekyll + GH Pages you have full control of your site with as little complexity as necessary.

Here's some more info: http://joshualande.com/jekyll-github-pages-poole/

[1] http://docs.getpelican.com/en/3.6.0/content.html#translation...

As long as you have that covered that is all you really need for good SEO - the rest is keyword research, quality content, links, etc.

But, of course, afaik, there's no plugin with nice explanations and checkboxes to configure that stuff.