10 things I hate about Git | Hacker News Reader

10 things I hate about Git

steveko.wordpress.com

28 pointsfogus32 comments

Git is a generic management tool for a directed acyclic graph, applied to version control. Once you internalize that, everything falls into place, trivially.

While you're right, and any educated programmer should understand the only technical concept in that statement ("directed acyclic graph"), I can't help but be reminded of "A monad is a monoid in the category of endofunctors, what's the problem?".

As it happens, I am currently studying category theory, so your analogy breaks down for me. Yes, being efficient in this world requires knowing advanced concepts.

And the advantage of things like SVN is _not_ having to understand advanced concepts in order to have your code sitting in a nice versioned repository.

The only "advanced concepts" in Git are commits and pointers to commits. Branches are pointers, tags are pointers, commits have pointers to their ancestors, HEAD is a pointer, and so forth. Then you have the working tree, index, and stash. The working tree is just the files in your directory, the index is what you're about to turn into a commit, the stash is what you're hiding from your working tree.

If you understand the concept of a linked list you can understand Git with a few minutes of effort, and if you don't understand the concept of a linked list why the hell are you a programmer? Sometimes we need to interface with designers and copywriters, but considering the disadvantages of SVN that's not a hard tradeoff.

11. Github.

Don't get me wrong - Github is an excellent site, well built and very useful. However there is a rapidly growing trend of people taking Github as the only place open-source software can live, while I choose to host my own repositories. Github is becoming the Facebook of open-source.

Am I the only person who feels this way?

I've been noticing the ramifications of a consolidation around github for a while.

The first was when I heard about githire. And there were other people were saying that they wanted to see your github user-page as a resume (or they wanted the much more sane but still very flawed requirement: a github link on a resume).

Yesterday I was on an open source project's website looking for the repo link and just couldn't find it, pages that talked at length about how open source they were had no link, the download page had source tarballs but no link. Then my mind clicked: they're using github and just assume that its the only place people anyone would ever look for source. Ten seconds later I had found the source on github.

Right now it just seems like a curiosity (I probably wouldn't want to work for someone with such harebrained hiring process anyway) but I do worry that the trend might have some bad implications in the future.

It seems like no matter how much time I spend trying to learn git and its commands I still continue to only understand a tiny sliver of them. The rest I figure out by browsing random stackoverflow questions as the need arises.

You should read http://progit.org/book/ if you really want to get better at git. Git is a hard tool to learn passively.

I had similar problems learning git. Then I stumbled across this site: http://gitref.org/ and it was like a light bulb clicked, and it just started to work. Not sure if it's because it was the best beginner reference I came across, or because I finally got enough information to push me over the edge.

The more advanced stuff just comes as you use git more, and because once you grep the easy stuff, being able to understand bits and pieces of the man pages allows you to gradually learn more.

I don't understand why people equate rebase with lying. I work on a team of 12 devs, and pre rebase workflow, gitk sort of looked like a rainbow due to it showing the actual interactions of each developers branch at the chronological time it happened. It was so complex that git bisect often couldn't find bad commits unless you used it a specific way. Basically it made the history next to useless. Post rebase, we see branch work serially, which makes it easy to find a bad commit, and obvious to see the transformations of the main branch of code.

I think people who complain about this fall into one of three camps:

1 - Are not using a topic branch workflow, and don't understand the hell that wreaks in history 2 - Are doing fast forward merges to merge branches back into the mainline, which makes it hard to see the points that development finished and the merge actually happened. 3 - Are rebasing long lived branches

It is just such a common complaint, and I have yet to hear of any down side that actually makes sense to me as someone who has a fair understanding of git

>It is just such a common complaint, and I have yet to hear of any down side that actually makes sense to me as someone who has a fair understanding of git

Probably because gaining a fair understanding of git is damned hard. Why you want to do things, and what these actions are actually for is not clear from the topology of the terms that git uses to describe these actions.

Fair enough, git does have a hellish interface. That is a great complaint, and I totally agree with it. The "zomg history editing!" thing just doesn't seem to die though, even though git been out for quite awhile now, and has become quite popular

I think complaints about history editing have some validity - as a team leader, I definitely do not want the history of my project, warts and all, to be editable by junior members attempting to hide mistakes/flaws in the production flow. This leads to cacophony when time comes to figure out why things went wrong, if they do, somewhere in the past.

This is not what rebase is for. As a team leader, nobody can rewrite the history of your project but you.

Surprised to not see git-rebase cited in #3.

> git-rebase - Forward-port local commits to the updated upstream head

I avoided rebasing for the longest time because of that. If it had just said "puts your stuff in front of their stuff" it would've been a lot less intimidating.

My pet peeve has always been the staging area. It encourages partial commits which couldn't have been tested because they never actually existed in the filesystem.

I like rewriting history, though. If I commit A then B, then realize A was wrong, I test and commit a fix then autosquash it so my history goes A' then B. Historical commits which didn't work are worse than useless, and if someone branched from them, the sooner we all figure it out and fix it the better. And the ugly truth will still be there in the reflog for a month.

Could you explain your first point a little more, I'm not following what you're saying?

When I make two changes to foo.c, and use "git add --patch" to apply one change but not the other to the staging area, my next commit will contain a version of foo.c that was never present out in my working copy where I could compile it.

Git's stash and clean commands make it possible to test partial commits built up in the staging area pretty easily. There's even a section of the man page for stash that's titled "Testing partial commits". I think this is essentially the flow described there:

  emacs foo.c # make two changes
  git add --patch foo.c # stage only one change
  git stash save --keep-index # stash changes not yet staged
  git clean -f # delete untracked files, like build artifacts
  # now the files on disk are in the same state as what you are about to commit

Sure, it's more complicated than just not having a staging area, but it can be really useful, and it's really cumbersome to manually tease apart changes in the same file.

Thanks, I had missed that. It's almost as handy as the --patch option "git stash" didn't have.

It seems like there's a huge opportunity for big software player to develop a git clone that is understandable and has a great UI. I'm thinking of Microsoft. Build the thing right into VS, it becomes the new standard for business source code management.

Everyone talks up git, but few every seem to actually use it, or use it to its full potential. And I agree that this has a lot to do with a crappy interface.

If git is truly the next great step in source code management, shouldn't it be easy to use? Isn't that kinda the definition of great software? You shouldn't have to be a linux command-line cowboy to have to use and understand git.

Github seems to be slowly working towards that. Their mac app hides a lot of details, and does some things "magically" (stashing uncommitted changes when switching branches, for instance). Doesn't do it well enough for you to forget about Git, but it seems like something they're thinking about.

> stashing uncommitted changes when switching branches, for instance

Really? This scares me to death. I absolutely want to be informed when I have uncommitted changes. What an anti-feature.

It could be argued that it already exists and that its called mercurial. Functionally equivalent to git, but with a _much_ simpler interface and better windows support.

Git has a little more momentum, probably because of Linus' pedigree, but I'm convinced that mercurial is objectively a better Git DVCS.

It's called mercurial. Seriously. It may not have the "raw power" of git, but at least the developers make an attempt at decent user interfaces.

At work we have a VCS that is obviously trying to compete with git while adding in the buckets of functionality people who actually pay for a VCS demand. Its OK, nicer to use than git, but not as powerful either.

I think git-improved is only going to come from the open source space. The vcs we use is bloated enterprise-y nonsense that is packed with bells and whistles and is a resource hog, you're not going to get regular developers interested in it, but you're never going to sell many copies of a vcs without that nonsense so you have to have it to satisfy purchase requirements.

If a git-improved turned up tomorrow and showed everyone how to do it and cost $1, someone would just nick those features and toss them into git proper before git-improved could get any traction.

What git needs is some fresh porcelain. We started with just git plumbing, then got the porcelain, but I think that the porcelain should be rebuilt knowing what we know from years of using git.

> You shouldn't have to be a linux command-line cowboy to have to use and understand git.

No, you really should. Any programmer should be able to use the command-line as a prerequisite for calling themselves a programmer.

It is that attitude that we're all sick of.

Yeah, it's great that some people have the time and talent to gain deep understanding of their computer and software. Some of us just want to use great tools to actually build things and don't have the time to learn something new.

Version control shouldn't have to be hard. I don't understand why some programmers think it's a step backwards to use tools to make things easier. Yeah, maybe you lose some understanding in the abstraction, but not everyone who wants to use VCS needs to know deeply how it works.

A little history is due here :)

Git replaced BitKeeper (http://bitkeeper.com/), the first SCM deemed good enough by Linus to use for Linux kernel development. However, there was great discontent among the Free Software community because BK is a commercial product and Larry McVoy began withdrawing licenses to certain contributors, accusing them of violating the noncommercial license he provided at the time.

Linus then wrote git to replace BK, not because it was a deficient product, but because he needed to solve a political problem.

BK is still a great product - simpler than Git, but gives you 90+% of its functionality and is commercially supported by a very talented team.

You don't hate git, you hate that you have to use it. And that in order to use it you have to get smarter. Smarter about computers, and smarter about managing your code.

But don't be discouraged, git really is simple. It's dead simple. The command line syntax is super annoying, i'll give you that, but the underlying tech is a collection of simple concepts that meld into a complex powerful tool.

The first thing you need to do, is to stop thinking of git in terms of github. Git is designed to be a decentralized vcs, and you really need to think/learn about what that means. It's crucial. The prevalence of github means that most people will never even use it in a non centralized way, and while incredibly convenient, it undermines the learning process just a little.

The next thing you need to do, is just read progit -> http://progit.org/book/ . In fact that's really the first thing you should do. Stop thinking you can pick up git through osmosis and just read the damn book. At least by then if you still hate it you'll have more poignant issues to touch on.

Frankly speaking, although I like Git, your post doesn't address one of the more important points, especially for beginners:

The man pages are one almighty “fuck you”.

I have to agree. The examples the author picked are bad, but the rest of the documentation is not much better. It's rather unfortunate, since this is supposed to be an important resource for beginners. But when I look at the page for cherry-pick and I see in the description...

Given one existing commit, apply the change the patch introduces, and record a new commit that records it. This requires your working tree to be clean (no modifications from the HEAD commit).

...I can predict that newbies will have a hard time agreeing that Git is "dead simple". Because even if you understand what the command does in terms of the man page, the description does not tell you what you actually accomplish with it. Non-intuitive instructions are nearly as bad as non-existent instructions, and a beginner who wants to understand Git cherry-pick might as well ask Stack Overflow instead.

Reply on news.ycombinator.com