Comment by garyrob | Hacker News Reader

Comment by garyrob | Hacker News Reader

My son is creating a software project for a independent study project in high school. I've been nagging him for a while to use version control, and he hasn't done it. I think it's a bit intimidating to be handed a 400-page book on git when he has plenty of other work to do. And also, he doesn't really know, from personal experience, why version control can save him a lot of pain. So he just hasn't taken the time.

One problem is that even if he googles "git" to find a simple guide, it talks about the server interactions which, frankly, aren't necessary for him for a project like this, and make things a lot more complicated. He's not sharing code with anyone. And he backs up his hard drive regularly, so he's not worried about losing all his code due to a hardware failure.

As opposed to Subversion, git can be used usefully without a server (including the possibility of a local server process), which actually makes git easier to get started with than Subversion.

So I wrote him a very brief guide for that kind of very simple, one-person use. Another benefit: when he needs to share code, and starts to feel the need to do things like branching, he'll already know some basics of git and so it won't be a big jump to start harnessing more of git's power.

I thought I'd post my guide it to HN in case anyone else finds it useful for that type of situation.

Your useful guide aside: why not have him use mercurial?

git has a very steep learning curve and an interface only a mother could love. Mercurial on the other hand has a clean interface very similar to svn, and has all the advantages of git that you list above. And can be straightforwardly run over apache to boot. Also the command is one letter shorter than git.

First, I know git, and not mercurial.

Second, I don't think there is a steep learning curve for the subset included in my post.

Third, I think git has enough momentum that it makes sense for beginning programmers to focus on it. I suspect Mercurial will get a lower and lower percentage of the market place over time, because programmers will generally need to learn git at some point, and once they've done so, there is less reason for them to go against the tide on their next project by learning Mercurial. (An "increasing returns" situation.) Maybe I'm wrong about this -- it's just the sense I have. But, see this chart, which I think tends to validate it: http://www.google.com/trends/explore#q=git%2C%20svn%2C%20hg&...

Both are great, but for a beginner, I too feel that Mercurial is much easier to get started. You don't have to spend any time 'understanding' how it works, just 3-4 commands is all that it takes to use it.

> Mercurial will get a lower and lower percentage of the market place over time

Lots of big projects continue to use Hg, some even switching to it from Git (e.g. FB)

https://hg.python.org/

https://hg.mozilla.org/

https://code.facebook.com/posts/218678814984400/scaling-merc...

For purely local use I really don't think there's actually a substantial difference between mercurial and git in terms of interface, mother's love or not. When you start talking about running it over apache you've gone into a whole other use case (and suddenly you have apache as well...).

I also think this is a relatively old complaint. Git's interface has improved a lot in the 1.8-2.1 window of versions, and now gives pretty decent guidance on some of the hairier parts of itself even.

For the most part you are right. But the mercurial command line interface is phenomenally better and the basics of vcs work with much less cognitive overhead than git.

You can use subversion without a server; it's especially easy on Windows with TortoiseSVN. TortoiseSVN is one of the easiest tools to use for version control for single-person projects.

http://tortoisesvn.tigris.org/faq.html#noserver

http://stackoverflow.com/questions/2940276/how-to-use-svn-wi...

Git was a little abstract for me to comprehend easily using command line so I just didn't use version control. The concepts made sense in theory, and I knew there would be benefits, but it was difficult to really wrap my mind fully.

I recently began using Tower which gave me some visual cues to the concepts others seem to more easily be able to visualize in their head. Once I get more confident in my workflow I may go back and try using Git from the command line again to see how I like it.

i made a similar list when teaching others programming as well as for a friend so we could do some collaborative literary writing,

i think offsite storage, or publishing, is also of tier one importance and can be distilled to simple instructions:

(0) create an account with bitbucket for free private, or github for free public .. of course you will have to show 'git config --global user.name NAME' and 'git config --global user.email eMAIL@SITE.com', but this step is a one off and can easily be ignored after initial setup which you can be present for

(i) 'git remote add origin LOCATION', and 'git remote -v' if you forget where the repo is being sent

(ii) 'git push origin master', after ever session

(iii) 'git pull origin master', before ever session

I would add "you don't have to list any filenames on the commit line - use -a for all of them, or add them again one by one (or in groups) before calling git commit.

My younger brother is doing his project and he uses TortoiseSVN on windows all by himself. I think that would be a better start.

well, all these points valid for all DVCS, not just Git.

Reply on news.ycombinator.com