Hacker News Reader

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.

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.

$ [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.

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.

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...

http://merrigrove.blogspot.co.uk/2014/02/why-heck-is-git-so-...

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.

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.

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.

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.

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.

I see the ability to change local history as a huge benefit. Not only can I track changes but before I publish them I can make decisions about how to make them more presentable/understandable to other developers.

Exactly this. I get all the benefits of a DVCS, pushing and pulling from my private fork, distributing development between my home and office machines, never losing changes; and then when I'm ready to publish, I can go back and rationalize my commits (many of which are "git commit -am 'oh sbt'" sorts of things) into a useful history and issue a PR for the rest of the team to code review.

It's taken me a while to come around, but you'd have to pry rebase out of my cold dead hands now.

What people are really saying when they say you shouldn't write history is that your SCM shouldn't support work in progress checkins. Not supporting that just makes your SCM inflexible.

Sadly, Git users frequently do rewrite published history, by merging branches via "git rebase" followed by a fast-forward merge (i.e. replaying the branch on top of the target), all to maintain that wonderful linear "history". And that's a bad thing because it destroys information about the context in which a change was made. (I've been baffled a few times by apparently bad commits, before realizing they were rebased and did make sense originally.)

If they're rewriting published history, it's even worse than that, because it could change history that you are currently developing on top of, requiring some more advanced git knowledge to get your local repository into a correct state.

I have not found it to happen often though, for two reasons. First, it is widely agreed upon among almost all mildly experienced to highly experienced Git users that rewriting published history is a bad thing. Second, if it becomes a problem with new Git users doing this, you can turn of non-ff updates in the public repository, thereby disallowing this to ever happen, unless you go through all the steps to delete and recreate a branch.

If you're working with your local unpublished history, then it is your responsibility to make sure they still make sense in the context of newer updates from the public repo regardless of whether you rebase or merge. I can see how it would be confusing if people failed at this. I tend to find that more confusion results from people inflating the history with loads of one-commit merge bubbles everywhere rather than just rebasing their small changes.

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.

I look at it the same way.

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.

"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".

IC. I added the " -- " syntax because that's what it recommends when doing a "git status".