6 ms·

It's actually a good idea. People often don't bother version-controlling simple stuff because it's a hassle. Here's the thing that's funny to me: git is easy.

It's actually a good idea. People often don't bother version-controlling simple stuff because it's a hassle. Here's the thing that's funny to me: git is easy. Everyone (especially mercurial users) goes on about how horrible the UI is, but when I think of git, I think of how similar it is to RCS: easy, quick, and simple. With both, I can diff things and check in changes very quickly. I have a bunch of single files in RCS which I'm moving over to git because it's a no brainer: all the speed and ease of use with a ton of advantages (such as dead simple replication) if I ever need them.

encoderer 12y ago
I love git. I'm a git power user. I've used git as the datastore for a CRM I built. But I respectfully disagree. Git is not "easy." You've been conditioned. You and I know that it's very very hard to lose work or lose commits with Git. I'd say it's nearly impossible to do on accident. But in my first month with Git I rewrote several things because I messed up somehow and couldn't figure it out. I would hose my checkout and resort to doing a new clone. I've since helped run a big transition from SVN to Git and saw the same struggles there. Git is power tools for my code. I could never go back to SVN. But it's not easy.
- w_t_payne 12y ago
  I agree. Git is powerful, flexible, and (once you grok it) quite simple to understand ... but it baffles new users, and is a complete turn off for people who happen not to be software engineers, even those who are otherwise highly intelligent. I work trying to bridge the gap between a team of mathematicians and algorithms engineers, and a team of embedded software engineers. Most of the embedded software engineers "grok" git (after some practice), and are (fairly) happy using it on a day to day basis. The Mathematicians and Algorithms engineers, on the other hand, aren't really interested in getting to grips with Git (or any version control system for that matter). They'd rather spend their time thinking about mathematics and statistics. (Quite rightly). The decision to use git, whilst justifiable for many valid technical reasons, has definitely thrown up some additional challenges for me and for our organization.
- npsimons 12y ago
  $ [git init|mkdir RCS] $ $EDITOR somefile $ [git add somefile && git commit|ci -u somefile] Not that hard to use git as a replacement for RCS. A few extra commands (not going to quibble over the fact that RCS requires checkout before edit), but that's about it. The one thing I can see going for RCS is its granularity (in only tracking single files), but that can be as much a burden as managing whole git repos, ie it depends on the use case.
- jarek 12y ago
  It's easy to mess up a somewhat complex repo in git, but for versioning really simple things like rsync scripts or dot-files, where you have one committer, one branch, and a linear commit log, git's pretty easy. git init, git commit -am, gitk to view history or diff, done.
IshKebab 12y ago
Are you serious? Git is by far the least user-friendly version control system I've used (Mercurial being the best). Here are some longer articles explaining why git sucks so much (from a convenience / user friendliness point of view): http://reprog.wordpress.com/2010/05/10/git-is-a-harrier-jump-jet-and-not-in-a-good-way/ http://reprog.wordpress.com/2010/05/10/git-is-a-harrier-jump... http://merrigrove.blogspot.co.uk/2014/02/why-heck-is-git-so-hard-places-model-ok.html http://merrigrove.blogspot.co.uk/2014/02/why-heck-is-git-so-... http://stevebennett.me/2012/02/24/10-things-i-hate-about-git/ http://stevebennett.me/2012/02/24/10-things-i-hate-about-git... Version control is one of those annoying admin tasks that you have to do and what to think about as little as possible. Git makes you think about it a lot.
- sofal 12y ago
  Version control is one of those annoying admin tasks that you have to do and what to think about as little as possible. I disagree. Version control as a concept is inherently embedded in every software change you make as part of a team. Every time you coordinate a change with other people, you are participating in a version control task. Your VCS can either capture the inherent complexity involved or it can sit there and force you to hash out the complexities on your own before you invoke it. Either way, you will be occupied by the task of controlling versions of your code.
muyuu 12y ago
I use it all the time, but there are situations and environments where it's overkill. Same with Mercurial. For starters it requires installation and that they is effectively a deterrent for many people especially non-devs.
InclinedPlane 12y ago
Git is terrible. Git is typical of a tool built by engineers. It has good primitives but a clunky overall design and horrible UI. It does not naturally encourage the most effective modes of use. Hell, even the "best practices" of the git community are highly questionable (just rewrite history for aesthetic reasons, what could go wrong?). Git is highly tuned to the use case of serving linux kernel development. Many other folks have figured out decent ways to use it effectively as well but don't mistake that for Git being an unquestionably good tool or for it being "easy". Sure, the core workflow is pretty straightforward, but the fact that the easy stuff is easy is not a ringing endorsement of a tool. Good tools make hard stuff easier and easy stuff trivial. Make no mistake, I think there are lots of awesome parts of git, the most important being its distributed nature. It's trivial to setup a repository because everything is a repository. That's pretty potent, and git has some reasonably well engineered components inside of it which make it fast for many common use cases, which is fantastic. But a big part of why git has been so successful lately has been because it hasn't had a lot of competition. Much of the competition is either hugely expensive (perforce, TFS), doesn't match the use case (same), hugely outdated (SVN), or terrible (TFS). The main competition for git is Mercurial, and a big reason git won out over Hg is because of mindshare traction and network effect from linux kernel development and then github. The biggest problem now is that so many git fans are afraid of criticizing git's shortcomings.
- sofal 12y ago
  just rewrite history for aesthetic reasons, what could go wrong? I have never understood the problem that some people have with the idea of rewriting history. It's as if the very idea of it offends them. Do file system writes also put you off? Is it important that I see the history of every single keystroke you made while twiddling with your config file? When you fixed a typo you made in a comment before publishing your change, how is this not a "rewrite of history for aesthetic reasons"? Do you really need to know about all the tens of little WIP commits I made because I just wanted to back up my changes before going to the bathroom? Am I not allowed to clean up a little bit before I publish all my own changes to the world? Now if you're just talking about rewriting published history, then nobody is going to disagree with you.
forrestthewoods 12y ago
Git is so easy a good search for "git tutorial" returns 2.7 million results. I've lost track of how man HN Front Page posts there have been trying to explain just how easy git is. The sheer volume of posts desperately trying to show how easy git is should be enough evidence to prove that it is infact not easy, simple, or intuitive.
- tk42 12y ago
  I look at it the same way.
digisign 12y ago
I'm liking git for it's internals, but the UI is pretty bad in places: # undo commit git reset --soft HEAD~1 hg rollback # undo changes git checkout -- <file> hg revert <file> etc. I look up the git equivs up on stack overflow every time I need them.
- kazinator 12y ago
  "git checkout -- <file>" does not actually revert a file from the branch. It reverts it from the index. It's only a revert-to-branch operation if you don't have anything in the index. So if you land into one of those "gituations" where use of the index is being foisted upon you, it might not do what you are used to. There is also the flaw that the -- separator is not required for giving paths: "git checkout <file>" also works. So if you are trying to check out a branch or tag, and make a typo and accidentally type the name of a file which has unstaged changes, you lose them. It doesn't rename the original file to a backup like good old "cvs up -C file".
  - digisign 12y ago
    IC. I added the " -- " syntax because that's what it recommends when doing a "git status".

encoderer 12y ago

I love git. I'm a git power user. I've used git as the datastore for a CRM I built. But I respectfully disagree. Git is not "easy." You've been conditioned. You and I know that it's very very hard to lose work or lose commits with Git. I'd say it's nearly impossible to do on accident. But in my first month with Git I rewrote several things because I messed up somehow and couldn't figure it out. I would hose my checkout and resort to doing a new clone. I've since helped run a big transition from SVN to Git and saw the same struggles there. Git is power tools for my code. I could never go back to SVN. But it's not easy.

w_t_payne 12y ago
I agree. Git is powerful, flexible, and (once you grok it) quite simple to understand ... but it baffles new users, and is a complete turn off for people who happen not to be software engineers, even those who are otherwise highly intelligent. I work trying to bridge the gap between a team of mathematicians and algorithms engineers, and a team of embedded software engineers. Most of the embedded software engineers "grok" git (after some practice), and are (fairly) happy using it on a day to day basis. The Mathematicians and Algorithms engineers, on the other hand, aren't really interested in getting to grips with Git (or any version control system for that matter). They'd rather spend their time thinking about mathematics and statistics. (Quite rightly). The decision to use git, whilst justifiable for many valid technical reasons, has definitely thrown up some additional challenges for me and for our organization.
npsimons 12y ago
$ [git init|mkdir RCS] $ $EDITOR somefile $ [git add somefile && git commit|ci -u somefile] Not that hard to use git as a replacement for RCS. A few extra commands (not going to quibble over the fact that RCS requires checkout before edit), but that's about it. The one thing I can see going for RCS is its granularity (in only tracking single files), but that can be as much a burden as managing whole git repos, ie it depends on the use case.
jarek 12y ago
It's easy to mess up a somewhat complex repo in git, but for versioning really simple things like rsync scripts or dot-files, where you have one committer, one branch, and a linear commit log, git's pretty easy. git init, git commit -am, gitk to view history or diff, done.

IshKebab 12y ago

Are you serious? Git is by far the least user-friendly version control system I've used (Mercurial being the best). Here are some longer articles explaining why git sucks so much (from a convenience / user friendliness point of view): http://reprog.wordpress.com/2010/05/10/git-is-a-harrier-jump-jet-and-not-in-a-good-way/ http://reprog.wordpress.com/2010/05/10/git-is-a-harrier-jump... http://merrigrove.blogspot.co.uk/2014/02/why-heck-is-git-so-hard-places-model-ok.html http://merrigrove.blogspot.co.uk/2014/02/why-heck-is-git-so-... http://stevebennett.me/2012/02/24/10-things-i-hate-about-git/ http://stevebennett.me/2012/02/24/10-things-i-hate-about-git... Version control is one of those annoying admin tasks that you have to do and what to think about as little as possible. Git makes you think about it a lot.

sofal 12y ago
Version control is one of those annoying admin tasks that you have to do and what to think about as little as possible. I disagree. Version control as a concept is inherently embedded in every software change you make as part of a team. Every time you coordinate a change with other people, you are participating in a version control task. Your VCS can either capture the inherent complexity involved or it can sit there and force you to hash out the complexities on your own before you invoke it. Either way, you will be occupied by the task of controlling versions of your code.

muyuu 12y ago

I use it all the time, but there are situations and environments where it's overkill. Same with Mercurial. For starters it requires installation and that they is effectively a deterrent for many people especially non-devs.

InclinedPlane 12y ago

Git is terrible. Git is typical of a tool built by engineers. It has good primitives but a clunky overall design and horrible UI. It does not naturally encourage the most effective modes of use. Hell, even the "best practices" of the git community are highly questionable (just rewrite history for aesthetic reasons, what could go wrong?). Git is highly tuned to the use case of serving linux kernel development. Many other folks have figured out decent ways to use it effectively as well but don't mistake that for Git being an unquestionably good tool or for it being "easy". Sure, the core workflow is pretty straightforward, but the fact that the easy stuff is easy is not a ringing endorsement of a tool. Good tools make hard stuff easier and easy stuff trivial. Make no mistake, I think there are lots of awesome parts of git, the most important being its distributed nature. It's trivial to setup a repository because everything is a repository. That's pretty potent, and git has some reasonably well engineered components inside of it which make it fast for many common use cases, which is fantastic. But a big part of why git has been so successful lately has been because it hasn't had a lot of competition. Much of the competition is either hugely expensive (perforce, TFS), doesn't match the use case (same), hugely outdated (SVN), or terrible (TFS). The main competition for git is Mercurial, and a big reason git won out over Hg is because of mindshare traction and network effect from linux kernel development and then github. The biggest problem now is that so many git fans are afraid of criticizing git's shortcomings.

sofal 12y ago
just rewrite history for aesthetic reasons, what could go wrong? I have never understood the problem that some people have with the idea of rewriting history. It's as if the very idea of it offends them. Do file system writes also put you off? Is it important that I see the history of every single keystroke you made while twiddling with your config file? When you fixed a typo you made in a comment before publishing your change, how is this not a "rewrite of history for aesthetic reasons"? Do you really need to know about all the tens of little WIP commits I made because I just wanted to back up my changes before going to the bathroom? Am I not allowed to clean up a little bit before I publish all my own changes to the world? Now if you're just talking about rewriting published history, then nobody is going to disagree with you.

forrestthewoods 12y ago

Git is so easy a good search for "git tutorial" returns 2.7 million results. I've lost track of how man HN Front Page posts there have been trying to explain just how easy git is. The sheer volume of posts desperately trying to show how easy git is should be enough evidence to prove that it is infact not easy, simple, or intuitive.

tk42 12y ago
I look at it the same way.

digisign 12y ago

I'm liking git for it's internals, but the UI is pretty bad in places: # undo commit git reset --soft HEAD~1 hg rollback # undo changes git checkout -- <file> hg revert <file> etc. I look up the git equivs up on stack overflow every time I need them.

kazinator 12y ago
"git checkout -- <file>" does not actually revert a file from the branch. It reverts it from the index. It's only a revert-to-branch operation if you don't have anything in the index. So if you land into one of those "gituations" where use of the index is being foisted upon you, it might not do what you are used to. There is also the flaw that the -- separator is not required for giving paths: "git checkout <file>" also works. So if you are trying to check out a branch or tag, and make a typo and accidentally type the name of a file which has unstaged changes, you lose them. It doesn't rename the original file to a backup like good old "cvs up -C file".
- digisign 12y ago
  IC. I added the " -- " syntax because that's what it recommends when doing a "git status".