3 ms·

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 do

by garyrob 12y ago

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.

beagle3 12y ago
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.
deleted 12y ago
[deleted]
- andrewstuart2 12y ago
  I'd argue that the one tool you need is something like git to make those small isolated snapshot copies for you. Learn a few commands and you won't have to worry about an ever-growing pile of directores that will just metaphorically topple over eventually. Then you can make changes ad hoc with confidence that you can quickly and easily revert if something breaks, without having to organize a smattering of cloned directories yourself. I guess what I'm saying is, the highest ROI for version control is to learn git add, git commit. At least you have the history well-organized for you down the road, with minimal effort on your part. If you need to revert at some point, you can just figure it out when you need it.
  - deleted 12y ago
    [deleted]
    - kasey_junk 12y ago
      To be fair that's a failing of the git user interface. Giving up on the entirety of version control because one of them has a bad UI seems like overkill.
      - deleted 12y ago
        [deleted]
- stormbrew 12y ago
  So instead of using a tool that does all this for you, he should do it all manually, himself, in the most tedious way possible? I mean if he was aiming to learn about version control this might be a good approach to teaching the pains that it solves, but git does all this with approximately 4 pretty painless commands: git add, git commit, git log, and git diff.
- chetanahuja 12y ago
  Wow. Either this is a fantastically straight-faced troll comment or you reeeeally missed the whole point of using version control tools.
  - deleted 12y ago
    [deleted]
wvenable 12y ago
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://tortoisesvn.tigris.org/faq.html#noserver http://stackoverflow.com/questions/2940276/how-to-use-svn-without-a-server http://stackoverflow.com/questions/2940276/how-to-use-svn-wi...
stevesearer 12y ago
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.
SeanLuke 12y ago
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.
- garyrob 12y ago
  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&cmpt=q http://www.google.com/trends/explore#q=git%2C%20svn%2C%20hg&...
  - chdir 12y ago
    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.python.org/ https://hg.mozilla.org/ https://hg.mozilla.org/ https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc...
- stormbrew 12y ago
  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.
develop7 12y ago
well, all these points valid for all DVCS, not just Git.
thewarrior 12y ago
My younger brother is doing his project and he uses TortoiseSVN on windows all by himself. I think that would be a better start.
justifier 12y ago
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

by garyrob 12y ago

beagle3 12y ago

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.

deleted 12y ago

[deleted]

andrewstuart2 12y ago
I'd argue that the one tool you need is something like git to make those small isolated snapshot copies for you. Learn a few commands and you won't have to worry about an ever-growing pile of directores that will just metaphorically topple over eventually. Then you can make changes ad hoc with confidence that you can quickly and easily revert if something breaks, without having to organize a smattering of cloned directories yourself. I guess what I'm saying is, the highest ROI for version control is to learn git add, git commit. At least you have the history well-organized for you down the road, with minimal effort on your part. If you need to revert at some point, you can just figure it out when you need it.
- deleted 12y ago
  [deleted]
  - kasey_junk 12y ago
    To be fair that's a failing of the git user interface. Giving up on the entirety of version control because one of them has a bad UI seems like overkill.
    - deleted 12y ago
      [deleted]
stormbrew 12y ago
So instead of using a tool that does all this for you, he should do it all manually, himself, in the most tedious way possible? I mean if he was aiming to learn about version control this might be a good approach to teaching the pains that it solves, but git does all this with approximately 4 pretty painless commands: git add, git commit, git log, and git diff.
chetanahuja 12y ago
Wow. Either this is a fantastically straight-faced troll comment or you reeeeally missed the whole point of using version control tools.
- deleted 12y ago
  [deleted]

wvenable 12y ago

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://tortoisesvn.tigris.org/faq.html#noserver http://stackoverflow.com/questions/2940276/how-to-use-svn-without-a-server http://stackoverflow.com/questions/2940276/how-to-use-svn-wi...

stevesearer 12y ago

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.

SeanLuke 12y ago

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.

garyrob 12y ago
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&cmpt=q http://www.google.com/trends/explore#q=git%2C%20svn%2C%20hg&...
- chdir 12y ago
  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.python.org/ https://hg.mozilla.org/ https://hg.mozilla.org/ https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc...
stormbrew 12y ago
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.

develop7 12y ago

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

thewarrior 12y ago

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

justifier 12y ago

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