
What I Hate About Git - gammarator
https://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/
======
dasil003
I found the #1 reason to be incredibly ironic:

> _The information model is complicated – and you need to know all of it. As a
> point of reference, consider Subversion: you have files, a working
> directory, a repository, versions, branches, and tags. That’s pretty much
> everything you need to know._

SVN's model is both simpler than stated here, but also much more complex to
reason about. First of all, svn doesn't have branches or tags, it just has
directories with cheap copy—tags and branches are just directories. The
repository itself is also watered down pretty severely because the actual
project directory is just nested in there somewhere with no formal locus. This
idea of "everything is a directory" sounds simple, but in practice it's a
architectural dead-end. The most obvious implication is that merging in svn
will always be fraught with peril because a branch isn't a first-class
citizen.

I used svn (and cvs before it) for much longer than git, and yet I never felt
I had any clue what svn was doing under the hood, and the experiences I had
over time instilled a fear of attempting to stray off the well-worn path of
the most basic commands.

Although the learning curve was steep, and the CLI quite confusing, the git
information model is actually much easier to grok because the primitives make
more sense. After 6 months using git, I had a firmer grasp of the internals
than I did after 10 years of cvs and svn. The idiosyncrasies of the UI don't
really bother me because they are just superficial flaws that are easily
memorized or looked up. The fact that I have the confidence to slice and dice
commits to any history I can envision, with or without a network connection
and remote repo, and do so with the reasonable confidence that I will never
lose anything (reflog) make git the best VCS I can imagine.

~~~
perlgeek
I fully agree. SVN traditionally had some things that simply didn't work,
often related to file renames.

I remember trying to rename a file after 'svn add' but before 'svn commit',
and it simply didn't work. Maybe that's fixed now, don't know. Or merging
stuff when a file was renamed in one branch and changed in the other.

During my several years of SVN usage I have regularly driven SVN checkouts
against a wall, where I didn't manage to recover them into a usable state, not
any combinations of revert, update or other commands. This has never happened
to me with git.

------
klodolph
Number 1-5 are mostly "I don't want to learn new things", so I'll ignore them.
Do you remember when you learned source control for the first time? I don't,
it was too long ago. Just like you have to learn SVN if you've never used
source control before, you have to learn Git if you've never used distributed
source control before.

* "Unsafe version control", and then gives examples using -f or +<refspec>, both of which advertise their destructive nature. Yes, you can also go in with SVN and obliterate history too, using svnadmin dump and svnadmin load. Git's reflog will have your back when you make mistakes, as long as the mistakes don't get too old.

* "Power for the maintainer, at the expense of the contributor" Yes, most people write code on one branch for a long period of time. Git does this just fine.

* "Burden of VCS maintainance pushed to contributors" First of all, nobody says that contributors have to merge. That is a decision that each project makes. Plenty of projects have the lead developers merging in everyone else's work. Second, the reason this is even an issue is because merging is such a pain in SVN that most people don't want to do it.

* "Git history is a bunch of lies" Again, this is up to the individual project. Some developers like to work on six different things at the same time, and then they go back and rewrite history so that their six changes end up as six commits. The difference with SVN, is that these same developers would simply avoid committing until they're done with all six changes. Some projects expect rebased patches, some prefer proper merges. Worse, the author says that "filtering" should solve this problem, but doesn't propose how such a filter would work.

* Complexity of simple tasks: Let's try not to artificially inflate the complexity of the Git tasks. For example, the Git examples assume no commit access, whereas the SVN examples assume direct commit access. If you don't have commit access to an SVN project, how do you do it? You either use git-svn and mail them a patch, or you use svn and mail them a patch.

A recurring complaint seems to be that "git add" is not the same as "svn add".
I don't see why it would be. It's not the same as "ssh-add" or "useradd"
either.

~~~
ender7
Like others, I think telling people to RTFM is unhelpful.

The OP already pointed out that the official Git documentation is bad, bad
_bad._ So, already it's not just "RTFM" but "Google around for a decent Git
tutorial and hope you pick the right one." Great.

Add to this the fact that the Git commands are simply _poorly designed._ Yes,
it is possible to understand what they do after expending a significant amount
of time simply learning to think like Linus, but _why should we have to do
that?_ I refer you to the gitref.org entry for 'git reset':

 _git reset is probably the most confusing command written by humans. I've
been using Git for years, even wrote a book on it and I still get confused by
what it is going to do at times._ [0]

This is not a problem of people not wanting to learn DVCS concepts. This is
simply people who don't want to jump through a set of arbitrary, confusing,
and completely unnecessary mental hoops in order to get to the DVCS concepts
they wanted to use.

[0] <http://gitref.org/basic/#reset> (gitref.org is maintained by GitHub)

~~~
encoderer
> The OP already pointed out that the official Git documentation is bad, bad
> bad. So, already it's not just "RTFM" but "Google around for a decent Git
> tutorial and hope you pick the right one." Great.

I have a hard time believing that there are scores of software developers out
there who have learned their craft enough to want source control but are
somehow overwhelmed by the basic task of finding a good Git tutorial.

The real impediment that I've observed is developers that certainly _could_
learn Git but don't because they don't see it as a good investment. That's
where they're so, so wrong. Git is like power tools for your code. If you
embrace and learn it, you'll be much better off for it. Yes, SVN is easier.
It's also a lot less powerful.

And there's always Mercurial, which is very similar to Git and addresses some
of the confusing-API criticism.

~~~
CJefferson
The problem with git isn't following a tutorial, the problems I have had are
nasty corner cases. I have to keep looking up strange a-symmetries, like why
does 'git push' push just the current branch, and 'git pull' pull all
branches? Then I have to look up how to make 'git pull' pull just the current
branch.

Also, due to inconsistencies in how commands take branches, I sometimes
realise I have a branch called 'origin/stuff', when I meant to do something
with stuff on origin. It's also hard to find which branches are tracking what.
Of course, you can find the options to do all these things. But there are just
so many little things to learnt.

The fundamental question is, does the complexity of git come from the power it
offers over svn, or does it come from the most terrible UI I think I have ever
seen on a command line tool? I think it is the second.

I still use git every day, but I think it is putting usability by less
computer-savvy users back years.

~~~
EdiX
> like why does 'git push' push just the current branch, and 'git pull' pull
> all branches?

It's the opposite, "git push" pushes all branches and "git pull" only pulls
the current branch. I think it's because push will only do fast-forward merges
while pull will do any merge, and that could require a working directory to
exist (but why not make push just push the current branch?)

~~~
CJefferson
Sorry yes, I got the asymmetry the wrong way around :)

The problem this causes (for me) is that if I have commits in other branches,
'git push' will fail (as other branches can't be fast-forwarded), but 'git
pull' won't fix it. Of course, I can get around it, but it's annoying.

~~~
ben_h
You can configure `git push` to push just the current branch to its configured
remote, by setting 'push.default' to 'upstream'.

`git config --global push.default upstream`

The relevant docs (droplr'd, since you can't anchor-link into the online
manpages): <http://d.pr/Rlqn>

------
monkeypizza
Have people done hallway usability testing on git?

i.e. just take a smart undergrad CS major and record their screen (& audio)
while they try to figure out how to use it. I think this would definitely turn
up some tasks within it that are way harder than they need to be. Do people
really feel confident that learning git is a smooth process, not involving a
lot of swearing?

The answer you mostly hear when complaining about programming tools is that
you need to toughen up - yet startups are founded on the idea of not doing
this to their clients. Making processes super easy for clients is a good
thing, and we should gather information, find the common problem spots, and
fix them for our own tools! We shouldn't just keep insisting that the customer
(programmers) needs to toughen up and learn (as the default answer, anyway;
some things really are hard)

Why isn't there user feedback tool for man pages, where it asks "Was this
information helpful to you?" every time you use a man page? I bet the success
rate would be pretty low.

In general why isn't there any information about which man pages are good and
which are terrible? They just seem frozen in time. Compared to the analytics
startups get about their customers, info about man pages is nonexistent. Yet
there are probably ones out there which would be rated "useless" 99% of the
time, and have been for 10+ years with no change.

~~~
DeepDuh
I think you bring up some good points of open source projects vs. commercial
ones. In open source projects, most of the time when seeing critical feedback
by users you see those "it's open source, just change it the way you want"
comments. No one makes money, therefore no one depends on users being happy
about the software. That's why B2B is so attractive: Your users actually WANT
to pay you such that you are dependent on their happiness.

Maybe we should invent a new model that combines open source with paid
incentives for user desired changes. Let's say User A uses Gimp, sees
something that could be simplified or added. He can't program it himself but
what he can do is describing the feature he wants, possibly with screenshots
or even an interface prototype. He then auctions this on a marketplace
website. Other users can upvote or even chip in to A's auction such that the
probability of a good developer implementing it rises. Developers have their
profile with reputation, possibly linked with their stackoverflow reputation.
The change gets implemented within a branch of gimp, installable by anyone
using a modified package manager. If the maintainers of gimp like the change,
they can merge it in such that everyone profits - the number of user downloads
being a good indicator that the change is desired.

------
crazygringo
Amen! I've felt like this for so long.

Ignoring the unnecessary parts about GitHub, he hits the nail right on the
head with:

> _Git doesn’t so much have a leaky abstraction as no abstraction. There is
> essentially no distinction between implementation detail and user interface.
> ...Its weakness is the complexity of simple tasks._

I swear, someone needs to invent a Git-wizard program. Interactive with a
wizard-like interface, it will walk you through all the common kinds of tasks,
even if they're fairly advanced, explaining all the ramifications along the
way.

I haven't seen any programs like this -- all the GUI interfaces to git
basically just translate to command-line commands, instead of trying to help
you intelligently manage your workflow.

I don't think it would be easy to write a wizard interface like this -- it's a
UI designer's worst nightmare -- but it would certainly help.

~~~
peeters
> I swear, someone needs to invent a Git-wizard program. Interactive with a
> wizard-like interface, it will walk you through all the common kinds of
> tasks, even if they're fairly advanced, explaining all the ramifications
> along the way.

Sounds like a great idea for making _one type of workflow_ easy. The great
part about Git not having an abstraction is that it supports almost any
workflow. You can choose what flow is right for your project.

Which is, by the way, why the documentation is not task-oriented, it's data-
model oriented. The same command might be used for two completely different
tasks in two different processes.

Other tools that aim to make the basics for committing easy do so at the
expense of implicitly supporting only certain workflows. Think of something
like Perforce. You don't _enforce_ your process with Perforce, you _choose_
your process so that it will work with Perforce.

~~~
crazygringo
That's why I said it's a UI designer's worst nightmare.

Because there are a lot of different kinds of workflows, and I don't even know
how you'd begin to organize them. I mean, maybe it's not even possible.

It would just be nice if it were more possible to "ease into" Git, rather than
feel like you have to go through the equivalent of a college semester learning
it.

~~~
saraid216
> That's why I said it's a UI designer's worst nightmare.

This is the point where I think it's appropriate to link another front page
article: <http://news.ycombinator.com/item?id=4338845>

I've learned Git about the same way I've learned *nix systems and programming
languages in general: piecemeal, a step at a time, on a largely need-to-know
basis. It's been 4 years now and I feel like a complete novice, but I rarely
need to do anything other than (1) synching local with remote repo, (2)
committing a change, and (3) using a feature branch.

------
zobzu
Git is far from perfect. But, there's roughly half bullshit, half "yes but is
it really an issue?" things here to me.

Things like detailing the _github_ process and blaming _git_ just does not
work for example.

Blaming additional git features that svn simply does not have.. is also
nonsense to me.

Finally, you CAN rewrite history in svn, its just extremely painful. In git
it's not and.. its a good thing. I prefer USEABLE history than trashy commits.
And don't tell me its about having proper devs making commits. As pointed out,
you get external commits in git. You can't control them without refusing them
and then what? In svn you don't _even_ have the possibility to refuse them.

Don't get me started on how svn is way more about the maintainer due to
this...

~~~
dasil003
> _I prefer USEABLE history than trashy commits._

Yeah the other day I got into an extended debate about rebasing with another
dev who just didn't get this. He maintained that it should not be possible to
modify history because it all may be relevant later. I rebutted with a
question: do you want a commit every time you type a character in your text
editor? Version control is just another tool for code craftsmanship. You
should strive to make your commits as atomic and well-described as humanly
possible. git-add -i and git-rebase -i are tools that allow you to approach a
more perfect history.

~~~
Animus7
> I rebutted with a question: do you want a commit every time you type a
> character in your text editor?

I don't get it. I want a commit every time I say I want a commit, not upon
arbitrary criteria the software decides for me. And I want that commit to be
irrevocably and permanently immutable, because I said I wanted it and because
it might be relevant later. What am I missing?

~~~
laughinghan
When you want a commit, you tell git to commit and it will commit.

When you don't want to revoke or mutate a commit ("irrevocably and permanently
immutable"), you don't tell git to revoke or mutate the commit and it won't
revoke or mutate the commit.

When you fucked up history and you want to change it, there are some simple
git commands to do this and some very, very tedious svnadmin commands to do
this.

Some of us fuck up history and want to change it. Some of us don't. Git serves
both of us well. Subversion only serves one of us well. A lot of the time we
have to use the same version control system, because we want to collaborate.

~~~
klodolph
Additionally, if I have admin access to the SVN repository and rewrite
history, how would you ever find out unless I told you about it?

In that sense Git has stronger support for immutable commits, since rewriting
published history will actually cause everyone downstream to stand up and
notice.

------
mrich
Excellent article, this reflects much of my personal experience working with
git in the last year.

Our whole department (>100 people) switched as part of a move towards
decoupled development/continuous integration, we used perforce before. Luckily
there were three people with excellent git knowledge who could answer all
questions so this helped a lot.

However, I find myself relying on stackoverflow/google for some not-so-common
small use cases where a glance at the manual just doesn't help (find all
changes in local branch not in upstream branch x?). Also, the git commands and
their options are sometimes not very logical as the article mentions (i.e. git
show vs. git blame, the first needs the syntax "branch:file", the second
"branch file", why? Small things like that take away from the beauty)

git is powerful and I prefer it to perforce for it's possibilities, but I
think tools like mercurial are a better DVCS which just didn't have enough
hype at the right time.

------
Kronopath
This generally sums up why I prefer Mercurial. It provides all the benefits of
a distributed VCS, but with less of the complexity, at the expense of some
(usually unneeded, at least for me) flexibility.

~~~
ajross
Given that "everyone" knows git, and essentially no one uses hg, I think
saying it involves "less complexity" is very much missing the forest for the
trees.

~~~
teilo
No one except for the entire Python development team. And me.

~~~
cpeterso
And all of Mozilla. And Oracle's Java dev team.

Windows support was a big deciding factor.

~~~
retrogradeorbit
And Adium and pypy and Sphinx and gevent and almost every project on
bitbucket. But _apart_ from them, "essentially no one" uses mercurial! :P

------
cheald
"If the power of Git is sophisticated branching and merging, then its weakness
is the complexity of simple tasks."

The power of Git is its distributed nature and the fact that you can maintain
local commits. When you have a single remote repository that everyone commits
to, then sure, it's really easy to do things (have fun maintaining the ACL and
merging any changes contributed by anyone outside the committer list via
patch). If you think "it's really easy to branch" is the primary reason to use
Git, you're using it wrong.

~~~
zalew
> The power of Git is its distributed nature and the fact that you can
> maintain local commits.

that's actually the power of any DVCS.

~~~
cheald
Yes, that was my point. He's comparing a VCS with a DVCS and then complaining
that the "D" adds overhead.

------
pydave
I think the biggest problem I have with git is that I don't understand how
people can't get it. (That's assuming they understand DVCS, but don't get git.
Not understanding DVCS is unsurprising.) It's like when my nonprogrammer
friends who took CS101 didn't understand for loops. What?! It's just applying
a concept you already understand.

It's unfortunate that git re-uses some verbs from cvs/svn with different
meanings, but is that really such a big hurdle?

And I'm always surprised to hear complaints about git's user interface. I find
the command-line interface far friendlier than others: auto-paging, colorized
output, text hints of what I should do next, and fantastic tools (like bisect)
in the same package.

And looking through my bash history, most of my commands don't use any options
(the biggest exception is git commit). Possibly this is because I do most of
my git interaction through vim-fugitive (and I have aliases for commonly-used
complex commands). But I think it makes more sense to have a smaller set of
commands that are logically organized (rebase mangles your history, reset re-
aligns based on your history, ...) than a single command for every function.

------
aneth4
Defenses of git sound remarkably like defenses of C++ syntax and feature
design. In fact, I'd argue they are similarly written by people who are overly
proud that they are smart enough to figure out some convoluted and arbitrary
complexity, but not wise enough to realize that level complexity is
unnecessary.

~~~
borplk
Your comment sums the issue amazingly well. Well you look at the user
interface it is clearly evident that these guys had forgotten that not
everyone is a kernel hacker. And it seems as if they tried their best to make
everyone else feel like an idiot because they don't have the time or want to
understand the arbitrary decisions they made or are simply not smart enough to
understand it.

------
MBlume
I'm all for trying to find ways to improve Git's learning curve, especially
for non-technical users.

That said, if you're calling yourself an engineer, you've worked at a Git shop
for over a month, and you're still complaining about how "hard" it is? I have
absolutely zero sympathy. You're being paid twice the national average to do a
job that's supposed to be mentally difficult. You use version control every
day. Stop whining, learn to use your tools correctly, and stop subjecting the
rest of us to your crappy, disorganized commits.

------
simplesimple
Ever try to commpile git statically?

Git makes you believe it's lots of small little utilities that work together.

Far from it. Git relies on Perl or another scripting language, not to mention
it's reliance on curl.

You cannot run Git without these other sizeable programs.

I can make static binaries of RCS, CVS and SVN no problem. CVS uses SSH. No
silly SSL and the certificate mess. I value the simplicity.

Mercurial (which seems to be a favourite among connoisseurs of versioning
systems) relies on a Python intepreter, but it's reasonably contained to a
single Python script; no installation required. You point Python at hg and it
works.

Of course, it's been said that most of the time people who ramble on and on
about these systems and their esoteric features do not need the advanced
features. They rarely use them, except as points in a debate over which
versioning system is "the best".

~~~
jlgreco
This is, by far, the strangest git complaint that I have ever heard. What are
you trying to do, ship embedded devices with git on them?

~~~
develop7
"avoid holding it that way"?

~~~
jlgreco
Honestly? Yes. Sometimes that is just the only reasonable response.

~~~
develop7
is there a complete list of ways I should avoid to hold git?

------
sigil
I love git and prefer it to svn, but he's right. It succeeds in power and
usefulness, but utterly fails in the complexity department. Someday, someone
who understands the virtue of simplicity and can control their "how dare you
insult my favorite tool" response will take this criticism to heart and rework
git (or at least, re-porcelain it).

~~~
klodolph
I think the re-porcelain option is really the most viable option here, for
those who complain about git's arcane invocation. So many Git commands
actually do two or three different things depending on invocation.

------
drucken
Sounds like someone's just discovered how different DVCS are to centralized
VCS.

Still, tools like Tower, Smartgit and Github for Windows, especially Tower,
make interface to Git less painful.

With time, the interfaces to Git workflows can only improve, whereas what can
you do with SVN?

That said, he may have a point about (branch &) merge message management in
Git. Perhaps this can be improved closer to git with git extensions, e.g.
implementing some sort of ranking and filtration system. Related to that is
users should not really have to change the structure of the VCS itself just to
filter messages.

------
markkat
I have to admit, it confuses the heck out of me. I am always in fear of
destroying code because the documentation part is spot-on. I read and reread,
and still feel like I am working on a best guess interpretation.

~~~
chris_wot
Using man files and in-built help is probably always going to only give you
half the story. Have you considered reading the Pro Git book? <http://git-
scm.com/book>

------
pka
I can't count the number of times I've googled for simple commands like "how
do I revert an uncommited file to its original state"?

    
    
        hg revert bla.txt
        git ???
    

... and I would still have to google for it (it's something with HEAD iirc).
Its usability is atrociously bad and I don't want to spend time learning some
badly designed cli interface when I can focus on more important things and use
tools that make my life easier, not harder.

~~~
greghinch
git checkout bla.txt ? I'm not sure how I get how that's harder. I'll throw
one back, how do I do the equivalent of git stash and git cherry-pick in hg?

~~~
pka
Ah, good to know. Everytime I've googled this it was something about reset
--hard (or --soft) and HEAD or ^HEAD or whatever else.

git stash is hg shelve. Don't know about cherry picking (I've never needed
it).

Anyways, the argument I'm making is not "which tool is more powerful" but
"which one is easier to use while being powerful _enough_ ". For me that is
Mercurial, hands down.

~~~
greghinch
cherry-picking is amazing for the "oops I did that fix on master instead of
the 2.x branch". git cherry-pick <hash>. done.

~~~
pka
Just for the record, the transplant extension [1] seems to be how you do
cherry picking in Mercurial.

[1] <http://mercurial.selenic.com/wiki/TransplantExtension>

~~~
retrogradeorbit
Transplant is a great extension and very useful in a pickle.

------
eli_gottlieb
I can say this: I've used both Mercurial and Git professionally, and for
distributed version control, I found Mercurial _much_ simpler to use.

------
rogerbinns
My issue with git is the defaults. Generally the defaults and behaviour are
geared towards large projects. It is absolutely correct in that sense - you
don't want hundreds or thousands of contributors messing things up. An
additional simple example is that push doesn't send tags.

But generally you want the opposite defaults for small projects/number of
users. For example you do want tags pushed by default so every sees them. This
places a large learning curve on the small scale projects and users. Remember
that most users will be perpetual intermediates.

My analogy is that git is like a sharp knife. In the hands of an expert it can
produce art, but in the hands of others we get blood. Some of the responses
here are marvelling at the sharpness and what can be done with it, but are
missing the point that others end up bloody!

~~~
dasil003
Aren't you more likely to cut yourself with a dull knife though?</strained-
analogy>

~~~
tharax
I think you're more likely to feel pain with a dull edge, but a sharp edge
cuts easier.

~~~
dasil003
The point is it slips off the tomato and cuts your finger.

------
dcosson
I find his complaint about git's lack of abstraction strange. Yes, git's
syntax could definitely be more consistent, but I can't think of how you could
abstract away very much of git without quickly losing power.

On the other hand, one of the things I hated most about svn is that it doesn't
abstract away the remote repository details at all. To do something as simple
as check out a branch you have to type in the full absolute url to your
repository, since a branch is basically a different folder higher up in the
hierarchy. Talk about a leaky abstraction.

The abstraction between version control tools and the remote server(s) you
back everything up on and the power of git's underlying model are both such
big wins that I really can't get too worked up about the syntax.

------
InclinedPlane
Yet another anti-git rant which will merely bounce off the deflector shields
of the git faithful. I doubt anything will change in terms of git usability
and misfeatures until someone proves that there's a better way to do it by
building an alternative that's all around better than git. But that raises the
question of why one would continue to use git at that point.

~~~
ern
Using Mercurial daily, I don't understand why it isn't widely viewed as the
alternative to git that you mention. It seems to avoid some of the pain-points
the OP lists.

The idea that there are "git faithful" is a sign of how immature (in every
sense) the software development field is. Masochism and complexity-worship
seem to blight our field(not necessarily referring to git, which I'm not
qualified to comment on)

------
tux1968
Git is _awesome_. Once you "Get it", there really is no big problem. Sure you
may have to look up some syntax occasionally and make an alias or two for your
common uses, but really, it's no big deal.

And the benefits are compelling. Enjoy the amazing power of committing early,
and committing often. Being able to revert to "10 minutes ago" is so freeing
when trying out a refactoring idea. And being able to "uncommit" the last X
commits to recommit them in a different order and with cleaned up messages and
structure before sharing with colleagues... amazing.

All the quibbles about syntax really miss the point and the power of Git.

------
akkartik
He mentions three ways to irrevocably lose data. Is that really accurate? I
would think old refs are still present in the repo and accessible from
.git/logs, but I don't have any experience actually collaborating with git.

~~~
ben_straub
Rebasing isn't really destructive. Try it: open `gitk --all`, do a rebase -i
and squash all the commits together, then switch back to gitk and refresh.
You'll see all the old commits still in the database, but the HEAD and master
branches point at the new commits. Totally not destructive, but it does take a
bit of knowledge to undo the change.

Git maintains what's called a "reflog" to help with this. It's a record of
every place that every ref has ever pointed in your repository. Try it: `git
reflog master`. You can even see when you did pulls, and what they merged in.

The only truly destructive thing you can do to your git database is `git gc`.

~~~
aneth4
> The only truly destructive thing you can do to your git database is `git
> gc`.

And of course we should expect garbage collection to be destructive of
information that is not garbage?

Didn't know that? Just read the man page. Whoops, it doesn't actually mention
that, but it does mention that it may happen automatically at times.

So only clever people like you know archaic undocumented side effects of git's
inscrutable design, except nobody ever really knows the full story because
there is so much unnecessary crud to learn in addition. Clearly more can be
destructive than gc if gc can be executed by other commands and triggers by
repository state.

~~~
jeltz
git gc be default does only prune things older than 2 weeks so to lose your
recently lost commits you would have to explicitly give a prune which is
today.

I do not think one can do this accidentally:

git gc --prune=2012-08-05

------
Karunamon
Allow me to add one to the list:

11\. Completely different concepts for the same commands as other SCM systems.

Case in point: Checkout. In every other system prior to git, going as far back
as CVS in 1986, checkout meant grab a remote repo and copy it locally.

In git, it suddenly means to switch branches in a repo you already have. The
real "checkout" was renamed to "clone".

Why not use something like "switch" instead?

That's nearly 20 years of muscle memory everyone needed to relearn because..
why?

Git add and SVN add do completely different things as well.

Was it simply not thought of that people who use git would be switching from
another system at the time, very likely to be either svn or hg?

~~~
chris_wot
Yeah, but you could also argue that it doesn't make as much sense in git to
call cloning a repository "checkout". Because you are cloning the repository
to your very own _local_ repository, then you make your changes from that
repository and then you push back to the original repository, which is a
_remote_ repository.

Essentially, a checkout in git is to checkout files from a particular branch
into the current working directory. And that branch is actually in the index,
which I would really call the repository - so actually you are indeed
"checking out" files from the repository. Once you make your changes, you
commit them right back into the index.

------
ecoffey
Dear OP,

If you're still using git from time to time and get frustrated please feel
free to ping @gitdoctor on twitter. It's an account I run to try and help
people use git right when they need that help.

Thanks and good luck!

------
patrickaljord
You don't need github to make pull requests:

[http://www.kernel.org/pub/software/scm/git/docs/git-
request-...](http://www.kernel.org/pub/software/scm/git/docs/git-request-
pull.html)

~~~
alexanderh
You dont need github for anything, period. So its very strange that it is
mentioned at all when comparing it to other version control systems.

~~~
lotyrin
Let me translate:

3 things I hate about (the culture surrounding) git(hub):

1,3,4,5 - I'm expected to understand the information model.

2 - The CLI is inconsistent.

6,7,8,9,10 - I'm expected to work harder so that life is easier for the
maintainer.

------
cypherpnks
Having used both git and hg, I very strongly agree. I learned hg first. Hg
took less time to master than git took learn the basics of. The syntax of git
is incredibly cumbersome in comparison -- I type a lot more. It's the
standard, but relative to hg, not a very good standard.

------
mattspitz
git is only complicated because it lets you do everything you may possibly
want to do, often a superset of what you actually want to do.

If you want svn-like commands, you can borrow someone's scripts or use a shiny
GUI. I don't want svn-like commands because centralized version control is
obnoxious.

Don't complain because it's hard. Programming is hard, math is hard, and if
you know how languages, data structures, and algorithms work, git is actually
pretty easy in comparison.

~~~
retrogradeorbit
I disagree. git is complicated because it does not have defaults, command line
intelligence and does not have a consistent user interface. It forces you to
constantly be repeating yourself and to learn a lot of detailed incantations
(Like mentioning HEAD and origin and master over and over.)

I say to you, don't complain that people are complaining. People are
complaining for a reason.

Have you tried some of the other DVCSes? Mercurial, or Darcs, or bazaar? Gits
problem is not the problem domain, nor the backend. It's the user interface.
That's the hard bit.

------
bendmorris
Git doesn't seem to have been developed with ease of use in mind. I've found
that it's very powerful, and that most things that you want to do with it are
possible, but not always as easy as it could be.

I'm working on a collaborative project with several inexperienced developers
using various editors and operating systems, and dealing with line endings has
been a serious time sink. The first step was "* text=auto" in a .gitattributes
file to override everyone's local settings, as some had used custom settings
when they installed Git.

Apparently the developers of Git decided to not support \r as a line ending,
which ended up causing headaches for us because some legacy programs still use
it. Several times, someone committed changes to a file where \r\n line endings
had been replaced with just \r, for whatever reason. To Git, they had just
deleted the entire file and replaced it with one long line. This frequently
resulted in edit conflicts where it was very difficult to tell what had
actually been changed.

The solution ended up being a filter:

    
    
        clean = LC_CTYPE=C awk '{printf(\"%s\\n\", $0)}' | LC_CTYPE=C tr '\\r' '\\n'
    

...which everyone now has to duplicate in each of their local .git/config on
every copy of the repository they use. Coming up with that little bit of
command-line wizardry, and getting everyone to install it (and making sure it
worked on Windows/OS X) ended up wasting the better part of a day to
accomplish what seems like a relatively simple task.

So, in the end it was possible, but the process could've been much friendlier.

I will say, though, that git bash is absolutely amazing and blows Cygwin out
of the water for ease of use.

~~~
keenerd
> ...which everyone now has to duplicate in each of their local .git/config on
> every copy of the repository they use.

You can use git in your .git. Add those hooks to the repository. Every dev
will get them automatically on checkout. No one should have to install
anything. (Well, aside from Awk.)

~~~
bendmorris
That never occurred to me. Thanks for the suggestion.

------
pbiggar
I'm going to be contrarian and say that he's mostly right for all of them. SVN
was simpler, git is more complex. SVN did some things well that git does not
so well.

But this all misses the point. Git is many many times more powerful than SVN.
And that complexity is really useful, even for relatively small projects. You
can learn Git's complexity, removing many of SVN's advantages. But you can
never get Git's power into SVN.

------
greghinch
I've been using git for several years on multiple projects with teams of
various sizes (admittedly none larger than 10, though I avoid projects of that
size for a multitude of reasons) and have loved it a lot. Especially compared
to the merge headaches of svn. Or cvs. And mercurial just gets in my way more
often than not. git stash I awesome

------
why-el
> The fundamental promise of any version control system is this: “Once you put
> your precious source code in here, it’s safe. You can make any changes you
> like, and you can always get it back. Git breaks this promise”.

Right there. I don't know who made this promise, but it's not what Git is
supposed to preserve. Git is distributable is it not?

------
paulhodge
Number 10 is a total apples-to-oranges comparison. For an apples-to-apples
comparison, the question is, do you want to give your contributors write
access to your master repo? (and deal with the consequences)

If contributors have write access, then Git is almost as easy. There's just
one more command ("git push") compared to SVN.

If contributors don't have write access, then there's no easy way to do this
with SVN. Most places that I've seen will either have users submit .patch
files via email, or put their changes in SVN branches (ugh). Or, they convince
themselves that they'd rather just give contributors write access. Either way,
Git has many handy ways to solve this problem (Github pull requests are just
one of those ways), and it definitely wins on this front.

------
rbanffy
I tend to summarize it like this:

Git is built by people smarter than you for people smarter than you. Deal with
it.

Now, seriously, Git is a) immensely flexible and b) born out of the needs of
Linux kernel developers (or, more specifically, Linus' needs). I would expect
it to be optimized for that case.

~~~
recursive
There sure is a lot of evangelizing for it if it's only intended for the 1%
elite developer.

~~~
j-kidd
That's exactly the problem, i.e. those people who endlessly promoting git so
that they can be seen as elite developer. Their favorite past time is to share
their "get it" stories with the rest of the world.

Not unlike the "Are You There God? It's Me, Jesus" episode of South Park.

~~~
rbanffy
Git is a tool. You use it if it solves your problem. You can certainly use it
the same way you'd use Subversion and it's not any harder - it'll just behave
as a version control system that can buffer commits offline with two "levels"
of commit - local and remote.

If you want to use the more complicated stuff, then there is no way to avoid
learning the more complicated ideas.

There is a lot I don't understand about Git, but, as far as my usage patterns
have gone, I'm very satisfied.

~~~
j-kidd
> You can certainly use it the same way you'd use Subversion and it's not any
> harder - it'll just behave as a version control system that can buffer
> commits offline with two "levels" of commit - local and remote.

That's hg. With git, you got the index / staging area, which is unique to git
(no idea if bitkeeper has it). In other tools such as svn or hg, there is no
need for flags such as "commit -a", "diff --cached", and "add -N".

> If you want to use the more complicated stuff, then there is no way to avoid
> learning the more complicated ideas.

And this is what we hate about git. Version control shouldn't be complicated
for 99.9% of projects. I have used svn for 3 years and hg for 2, they get the
job done just fine without cryptic commands and flags.

------
jimmyhchan
[http://stackoverflow.com/questions/115983/how-do-i-add-an-
em...](http://stackoverflow.com/questions/115983/how-do-i-add-an-empty-
directory-to-a-git-repository)

Git questions on SO with more than 300 upvotes should be considered bugs.

------
methodin
There are plenty of abstractions on top of git - most UI implementations
abstract away the hard details, at the cost of not being able to understand
what happens when something bad occurs because you never had to learn its
intricacies prior. Seeing the consequences of such things it makes me
appreciate git is left as raw interactions. Git is not for people that do not
want to understand it. To me, it's similar to vim - its basic implementation
is bare essentials and complicated concepts, but once mastered, far outweigh
competitors who roll those concepts up into simpler ones and leave you with
workflows on their terms.

~~~
anshumans
I completely agree with you here. Having used Visual Studio as my primary
editor for a long time, I finally decided to give vim a try last year given
how all my hacker friends raved about it. It definitely took a few days of
understanding the basic concepts and going over the steep learning curve, but
now I'm way more efficient with my coding than before.

It's been the same experience with git. It definitely has a steeper learning
curve, especially coming from a centralized source control system like TFS and
Perforce (for me at least), but having worked through that curve, I feel git
has been much more useful to my workflows than what TFS or Perforce (or insert
any central source control system) has ever been.

------
philwelch
> Power for the maintainer, at the expense of the contributor

Interestingly, SVN and Perforce are about power for the maintainer, _with no
benefit at all_ for the contributor. You can't even version control your own
work with those tools.

------
thangalin
Issue #10.

    
    
        alias commit='git add && git commit && git push'

~~~
pydave
I know what you're going for, but for anyone following along at home: "To
avoid confusion and troubles with script usage, aliases that hide existing git
commands are ignored." (from git help config)

~~~
davvid
This is true, namely that _git aliases_ in ~/.gitconfig cannot override git
built-ins.

That said, the parent post showed what looked like a bash alias, not a git
alias.

~~~
thangalin
The bash alias is correct. The issue was "too many commands", which is a non-
issue. You type in the commands _once_ , make it an alias, and be done with
it. When switching to another repository system, change the "commit" alias,
not what your fingers have to remember.

------
krosaen
git::mercurial vhs::betamax

I'll also say that tech folks don't like not being able to understand
something, and enjoy understanding arcane things others don't (and once
understood, no matter how hard it was to learn, it is suddenly "trivial"),
further strengthening git's hold. I'm happy to see the author seems to
understand git well enough to say, yes, I get it, and I still don't like it. I
just wish he had talked about mercurial as the plausible user friendly
alternative instead of svn, since svn is not distributed and therefor
unsuitable for the use cases where git thrives.

------
Fando
Whoever designed Git was both a skilled programmer and a crappy designer.

------
zaphar
I started dvcs with Darcs but it was too slow despite having a really really
good CLI. Then I switched to Git because it was fast and within a week ran
into so many sharp corners I had metaphorical blood all over my codebase.
After a while I learned the useful subset of Git commands and life got easier
with only an occasional sharp corner intruding every few months or so.

Then I discovered Mercurial. The speed was acceptable. The UI was
intelligible. And I didn't hit any sharp corners. Life has been way way better
ever since.

------
rjzzleep
i had to work on a big corp job once they were using VSS5 in 2007. made me
appreciate even CVS.

if you want to have a really simple way of working with git get the github for
mac client. at the same time insanely inflexible.

but hey you know what in theory vss5 is quite "simple" as well. i mean how
complex can a program be where distributed work is essentially happening by
locking files.

I had hoped op would've said something interesting that might've led into 3rd
generation DVCS, but this is definitely far from.

------
parasubvert
This sort of article sounds like s/unix/git/g of rants against UNIX/Linux
command line & filesystem concepts that were common in the late 90's, as it
was becoming clear that UNIX wasn't actually going to be killed by Windows NT,
but rather was resurgent. Examples included:

\- "Yuck, why such different terminology from DOS?" \- "Commands are
inconsistent and there are too many, where's my One Command or (better yet)
One GUI that does everything they way I think about it?" \- "Yuck, scripts
that make things easier for my particular workflow, why didn't they just build
it right the first time?"

Fundamentally it comes down to people who believe version control is a simple
problem, and git confuses that for no good reason, or those who believe
version control is an inherently complicated problem, and tends to require
some study to understand the concepts. Git doesn't hand-hold, it exposes the
core concepts at the _data level_ , thus supporting any workflow for any size
of team or work style. If you prefer a dictated workflow and task structure,
there are plenty of wrappers that will help you - just don't be surprised if
not every team agrees with your preferred workflow.

~~~
pwang
> it exposes the core concepts at the data level

But it exposes them _poorly_ , from a user interface standpoint. The beauty of
UNIX, actually, is that it provided a few simplifying abstractions (block
files, character devices, pipes), and everything used that. Imagine if catting
the contents of something from /dev was different than piping the contents of
a tarball. That's the sort of UI/UX frustrations that TFA (and others) rant
about.

This is not a "DVCS vs. SVN/CVS" issue. This is about git's usability.

------
hawleyal
OP might have just professed "I am not technically advanced, Git has powerful
features I'd never use, it should cater to me."

In general, there are too many of these articles on HN about "I don't know how
to use it, so it's terrible."

What OP fails to grasp is the purposeful difference between Git and other
revision/version control systems. Git attempts to cover anything you would
ever want to do. Git is the Photoshop to SVN's Instagram.

You can use Git as if it were SVN, no problem. You can do Git commit-push-pull
all day long as if you were SVN commit-update, and be none the wiser.

The one thing Photoshop has (as a similarly complex piece of software) that
Git doesn't have is a single user interface. I don't see this as a problem.
There are a bagillion Git GUI clients if you don't like the command line. Some
are good, some aren't.

As far as having a good strategy for using Git on a real project. I think OP
needs to spend some more time on Google. Here's a good article describing the
most common workflow:

<http://nvie.com/posts/a-successful-git-branching-model/>

------
countzeroasl
As a new DVCS user, I today just started playing with both using tutorials and
books freely available on the web. I am using Mint 13 and the CLI. Of the two,
the feel I get is that Mercurial is easier (more straightforward) of the two
to use and Git is the more micromanage-able of the two. JMHO, but as a
newcomer, it's my impression.

------
mncolinlee
I especially liked the first comment about Subversion "anybody can write a
simple VCS if they don’t have to make it distributed." It reminds me of my
days working on a parallel compiler team. We always used to say, "we can get
you answers very, very quickly if you don't mind whether they're correct or
not."

Just as a parallel compiler developer must worry about recurrences and data
dependencies breaking parallel programs, distributed version control adds a
huge level of complexity which you cannot safely hide. However, I agree with
the poster that the next major version of Git should clear up several
inconsistencies.

(As a side note, some binaries labeled as ASCII in our Subversion repository
back then caused massive corruption and shut down all development for days.
Having too many assumptions made by your VCS and too few options specified by
developers is bad simplicity!)

------
shredfvz
Subgit and Subhg are interesting.

[http://rustyklophaus.com/articles/20100124-SubmodulesAndSubr...](http://rustyklophaus.com/articles/20100124-SubmodulesAndSubreposDoneRight.html)

Just use Mercurial for random private commits, send the Git people your
changesets every so often:

    
    
        $ git init && git add . && git commit -m "Initial commit" && git remote add origin git@github.com:acct/repo.git && git push -u origin master
        $ subgit setup
        $ hg init
    

hginit.com <\-- great resource

<http://code.google.com/p/support/wiki/DVCSAnalysis>

In Google's own words: "In terms of implementation effort, Mercurial has a
clear advantage due to its efficient HTTP transport protocol.

In terms of features, Git is more powerful, but this tends to be offset by it
being more complicated to use."

------
chousuke
I really can't agree with point #1. Most of the things he lists as being part
of the complex information model are _equivalent_ and make perfect sense once
you take a couple hours to understand how git works internally.

And no, that's not too much to ask for a tool that you will be using nearly
every day. Once you understand git's data model and "patch-oriented"
behaviour, you won't have to wonder about namespaces, the index, rebasing,
cherry picking or fast-forward merges.

Point 5, or the fact that Git doesn't even try to hide its internal workings
is actually why I prefer it over everything else. The UI can be weird at times
since it evolved from just a collection of tools to operate on an on-disk,
persistent and immutable data structure, but as far as being good at what it
does, it's hard to beat Git.

------
loeschg
_Translation: “It’s easy, Granny. Just rev to 6000, dump the clutch, and use
wheel spin to get round the first corner. Up to third, then trail brake onto
the freeway, late apexing but watch the marbles on the inside. Hard up to
fifth, then handbrake turn to make the exit.”_

Haha!

------
chaostheory
I felt the article had some fair complaints. The problem is that the author
felt that going back SVN was the resolution to those complaints which I found
ridiculous.

My question is how does mercurial compare to git on all of the author's
points?

~~~
zalew
As someone who jumped from svn to hg a long time ago, I can answer simply: the
transition was smooth like butter, <http://hginit.com/> explains everything on
the concept, while hg's ui provides abstraction and is very svnuser-friendly,
so - everything just works. <http://hgtip.com/> is also very useful.

IMO it's easier to embrace git after mercurial, because the part where you
understand how a DVCS works is already behind you, and you jump into the
syntax and specific differences.

------
nicholassmith
The issue with git is that's got all this cruft built around it, but for the
most part it's very rare you need to jump into it in that level. I've been
using git for about 2 years and only needed to rebase for the first time very
recently.

There are issues, and flaming the author saying he needs to read more is
disrespectful (and ignorant of the issues), but git is a community, open
source project. Not happy with the existing docs? Rewrite them, call it git
for humans and off you go. I've seen projects doing work to 'nice' the command
structure, so there's other people attempting it.

But we can all agree git reset is _weird_.

------
snambi
I have used subversion heavily. So many things are not at possible with SVN.
But, it can be done in Git easily. Of-course, it requires learning and a bit
of change in the mind-set. But, it is worth it.

------
smoyer
I hate blogs that put pop-ups over part of the content with no way to close
them (I'm not subscribing to your mail list or following you).

I don't hate Git but I do agree with many of your points. There's ccomplexity
that should be hidden (or more hidden) and there's inconsistencies that still
catch me occasionally. I've never actually lost code on Git though it's taken
me a while to find my code.

It's also not fair to confuse Github's "Pull request", "Fork" and "Merge" with
Git. These are still just branches and merges.

------
chris_wot
1\. Not sure his issue here - I count 9 things you need to know for Github
(one of which I have _never_ needed to know - treeishes), and 7 things for
SVN. It's really not that complex.

2\. The command line syntax:

 _But the shortcut for “git branch” combined with “git checkout”? “git
checkout -b”_

Indeed. You can branch your code, but not check out the files from the index
into the working tree.

Perhaps the confusion here is because the author is coming from an SVN
background, where checkout means something different.

As for git am being obscure - sure, seems a little, but then there are two
things: 1. don't use it if you don't need it, and 2. for kernel development,
this is remarkably useful!

3\. Documentation: completely invalid. The man pages might seem a little
terse, but then if you are looking up a command and you don't understand the
terminology, then you should probably consider typing in

    
    
      man gittutorial 
    

Which, incidentally, can be found here:
[http://www.kernel.org/pub/software/scm/git/docs/gittutorial....](http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html)

Alternatively, if you are trying to understand how to use git (and it might be
worthwhile for the author to follow this advise) then try reading the git
user's manual, which can be found here:

[http://www.kernel.org/pub/software/scm/git/docs/user-
manual....](http://www.kernel.org/pub/software/scm/git/docs/user-manual.html)

Hint:

git rebase is explained here:
[http://www.kernel.org/pub/software/scm/git/docs/user-
manual....](http://www.kernel.org/pub/software/scm/git/docs/user-
manual.html#using-git-rebase)

To understand how git checkout works, read here:
[http://www.kernel.org/pub/software/scm/git/docs/user-
manual....](http://www.kernel.org/pub/software/scm/git/docs/user-
manual.html#how-to-check-out)

4\. Information sprawl: actually, I consider myself to be a git newbie (mainly
use github!) and frankly I've not needed to learn that much about git so far.
However, whenever I've come up against something new, I've checked the
documentation and after about 5-10 minutes I've understood the concept needed
to get me going. I don't consider myself to be an expert in git in any way.
However, as someone who has to program, I tend to find that for any system
with enough power, I have to learn new things regularly. git is one of those
things. Learn to love it :-)

5\. Leaky abstraction: first, don't make the title "leaky abstraction" if you
don't believe that there is any abstraction in the first place.

Secondly, it looks to me like they are trying to take your branch and insert
it into another repository? Can't quite tell what is required here...
certainly I'd love to see the way that this would be done in SVN!

6\. Power for the maintainer, not the user...

??? I'm sorry, but the author is complaining that git is powerful, and works
really well in highly distributed systems where you have a lot of parallel
commits? Well, uh... duh?

The complaint here is that it's not usable for "ordinary" repository users. I
would consider myself a fairly ordinary user, and I can honestly say that I
don't consider that git is that hard to use.

7\. Unsafe version control

DON'T DO THOSE THINGS!

8\. _In the traditional open source project, only one person had to deal with
the complexities of branches and merges: the maintainer. Everyone else only
had to update, commit, update, commit, update, commit…_

Which meant a massive bottleneck when doing branching and merging. That's the
whole point of git - it's version control done large. Or otherwise known as
"distributed version control". I'd recommend the author read up on some of the
advantages here: <http://git-scm.com/about>

9\. I don't really have much of an opinion on this.

10\. Github != git. For the record, I love github and I really don't find it
that hard to use, or anything so complex that I can't do it fairly quickly.

~~~
einhverfr
_Documentation: completely invalid. The man pages might seem a little terse,
but then if you are looking up a command and you don't understand the
terminology, then you should probably consider typing in..._

I think a cardinal virtue of documentation is to but info where people expect
to find it. Saying "Oh, you read the MANUAL. When I said RTFM, I mean the
MANUAL for the TUTORIAL" isn't much of a help. If the documentation isn't
where novices expect to find it, it doesn't exist.

 _Unsafe version control

DON'T DO THOSE THINGS!_

How many can be done by accident? Are you using revision control at least in
part for the ability to recover from a stupid accident? The fact that it isn't
safe means you can't count on it being safe. You can't use it as essentially a
way to have real point in time recovery for your repo, and it also means you
can't count on it being an audit trail because at a minimum it could bet wiped
out. That's fine, but it's worth stating up front that this is something Git
doesn't do very well. Fine. Understand it is a tradeoff.

~~~
chousuke
Doing those "unsafe" things in git by accident in a way that is unrecoverable
pretty much requires you to be so drunk that you wake up the next day not
remembering what you have done.

forcefully pushing things to remote repositories can be denied with hooks, so
if you really do not trust the people with push access you can use that. For
anything else, it's pretty much always possible to undo any damage by using
the reflog.

In my experience, git is the least unsafe VCS I've used. if I commit a file, I
know it's safe from accidental removals (as long as I don't touch .git). If I
push the commit to a remote (private or public. Could even be on the same
machine), it's safe from _anything_ I do locally. So if I am going to do a
complicated merge or a rebase, I first make a temporary commit to save the
state of the repository and ensure that I can always undo any mistakes. You
can't always do that in svn, since commits are immediately public.

~~~
einhverfr
_Doing those "unsafe" things in git by accident in a way that is unrecoverable
pretty much requires you to be so drunk that you wake up the next day not
remembering what you have done._

Or more likely not knowing what you are doing, getting disoriented and
combining the wrong options.

I haven't been using git for that long but I could totally see myself getting
confused and typing something like that in by accident.

~~~
andrewaylett
Even then, you can get back to something sane by using the reflog:
master@{yesterday} refers to the master branch as it was 24 hours ago, and you
can view the different things you've done to HEAD by just running `git
reflog`. It's really _really_ hard to blow away the reflog without meaning to
-- you're much more likely to just `rm -r` the whole repository by mistake.

------
jey
This is a pretty decent criticism of git's _current UI_. The good news is that
the core primitive operations underlying git are fine, and all that needs to
be done is to create a better UI out of them. There's definitely room to build
a great, user-friendly (commandline) user interface for git. I'd bet that the
existing high-level operations like "push" and "pop" were relatively late
additions.

------
y4m4
Yet another "i hate <this>" article :-)

~~~
chris_wot
Indeed. It seems to be a "I hate git, because I don't understand what it is
trying to achieve, and I haven't bothered to learn the concepts".

Unfortunately, this tends to invalidate many of the points he is making. The
author is assuming that git should work exactly the same way as subversion,
except that it has a fundamentally different way of viewing version control
and uses it's own terminology which can sometimes get in the way of those who
know subversion.

~~~
borplk
I think you are missing the point. The author is talking about unnecessary
complications. Git is unnecessarily difficult to work with and understand. He
is debating whether and how much of any of these is necessary. Sure we can
spend time and learn it, but why should it require this much learning in the
first place?

~~~
chris_wot
What part, exactly, is so hard to understand? All the examples he gives aren't
particularly hard to understand.

For example, he complains that git pull is actually git fetch and git merge...
well, that's pretty obvious. First you have to fetch the changes, then you
have to merge in those changes. What is particularly illogical about that?

Another example: he complains that _git branch_ combined with _git checkout_
is _git checkout -b_ (he forgets to note that you specify a branch name...).
What's so non-obvious or "insane" about that? First you create a branch with
_git branch newbranch_ , then you checkout files from a branch with _git
checkout <branch>_. The obvious shortcut is _git checkout -b newbranch
<branch>_: when you want to create a new branch, then you have to checkout the
files from a branch, and the -b creates a new branch for you before you do
that.

The only real thing that is a little tricky to understand is the concept of
refs, but even that's not really that hard to understand. Every commit has a
SHA-1 reference to it, and a branch is merely a reference to a particular
commit that is the head of a line of work.

Remote refs are about the only other type of ref that you need to know about -
all they are is a reference that points to a remote repository that you can
push to or fetch from.

Once you know what a ref is, most of the man pages make sense. Thus when the
man page for git-push says:

    
    
      git-push – Update remote refs along with associated objects
    

... you can see that it means that it will update the remote refs (remote
repositories you are pointing to). Which is what he says in his article, but
all he has to really do is understand what a ref is and he wouldn't be so
confused.

When you think about refs, they make logical sense - all they are is like a
"remote branch" of your repository.

As for complexity in the concepts, let's look at what he's complaining about:

 _...you have files, a working tree, an index, a local repository, a remote
repository, remotes (pointers to remote repositories), commits, treeishes
(pointers to commits), branches, a stash_

1\. Files - obvious

2\. A working tree - you do your work in the working tree

3\. An index - once you have made your changes in the working tree, you commit
your changes to the index

4\. A local repository/a remote repository - this isn't a particularly hard
concept to understand. You do you work in your own local repository. You might
get that repository from someone else. You make your changes in your own
repository, then you push those changes to a remote repository.

Not entirely sure what is so difficult about that concept...

5\. Remotes - again, not a particularly hard concept really, as he says these
are just references to remote repositories

6\. Commits - You work away on your code in the working repository (whatever
directory structure you so desire). Then you commit it to the index. Which is
not really any different to SVN, where you checkout a file from the SVN
repository, then you make your changes, then you _commit_ your change back to
the repository.

Explain to me again what is so hard about this concept?

7\. Tree-ish - This is an extremely advanced part of git that most users may
never encounter. You most certainly don't _need_ do know about this, though of
course it is always good to do so.

8\. Branches - we _are_ talking about source control? If so, what is the issue
here? Branches are not really any different in git than any other source
control system.

9\. Stashes - an extremely useful feature. If you are in the middle of working
on something and you want to switch branches, you normally don't want to
commit those changes. So what you do is "stash" the changes onto a stack. You
can reapply them later. Some excellent info can be found here: <http://git-
scm.com/book/en/Git-Tools-Stashing>

There... none of that was so hard, was it?

~~~
jebblue
>> All the examples he gives aren't particularly hard to understand. For
example, he complains that git pull is actually git fetch and git merge...
well, that's pretty obvious.

No, it isn't since the words fetch and pull mean pretty much the same thing to
most people.

>> What part, exactly, is so hard to understand?

Looking at the length of your comment...apparently a lot, for most people.

I've tried to like git, I want to like git, I don't get git. So ... in Eclipse
at least I use EGit to help me make git usable. Even with that tool to make
git easier to understand I still find it confusing (or confounding).

~~~
chris_wot
_No, it isn't since the words fetch and pull mean pretty much the same thing
to most people._

All I can say is that there are valid design decisions for seperating the two.
That's why they created the shortcut - to make it easier to do what folks
intend to do. When people do a pull, then they get what they want. That is the
common nomenclature of git, pretty much everywhere.

And to be clear, the man page for git-merge can't be any clearer:

    
    
      git-pull - Fetch from and merge with another repository or a local branch 
    

_Looking at the length of your comment...apparently a lot, for most people._

Which I would argue is because they are coming from SVN, and apply their
experience with SVN to git. That's not really a problem for git, IMO, but more
an issue for those who believe that SVN is the only way to go about doing
source control.

------
swdunlop
While I agree with the article in many of its finer points, the hyperbole
ruins its effectiveness. For example, I don't find it frequently necessary to
"log on to github and issue a pull request" to commit changes. Additionally,
github != git, blaming one for the sins of the other just muddles things
further.

------
salem
Point 10 is not a fair comparison, since the svn example does not cover
passing around patch files and trying to keep multiple svn repos in sync.

How can this article complain about syntax and documentation, but leave out a
discussion of submodules. As much as I like git, that's really the worst part.

------
tbatterii
What I hate about git is the religious fervor surrounding it. It's a tool. And
energy spent debating the good or bad of any tool could be better spent
building something amazing.

------
kapuzineralex
There's a lot of unfair or simply untrue comparisons in that post.

------
azat_co
Interesting point of view but it please try to learn your tools better next
time you write an article :) And try not be a hater, it only harms you and not
doing any good.

------
jnazario
thanks for a nice list. i also dislike git for many of the same reasons. i
think it's crap based on those reasons, and i'm saddened it's taken off.

------
chromejs10
I like GIT. If the man pages were improved to be more human readable then I
think a majority of all these "i hate git" articles will go away.

------
bitwize
This is why the big boys still use Perforce.

------
briandear
Another crybaby blog post by someone that wishes it were still 1997.

If git syntax is that hard, then programming might not be the correct
vocation.

------
BaseBand
Back to SVN via email, and flash drives! I'm so glad my last day is Monday.

------
hasenj
It would only take a week to properly learn git. Most people spend a lot more
time to learn a programming language or an operating system.

I consider git to be almost like a programming language.

The information model is not complex, it's actually quite simple if you really
understand it.

* blob: roughly a file (without a name)

* tree: roughly a dir (maps names to blobs and trees)

* commit: tree + parent commit(s) + meta data (author, commit msg, etc).

If you grok this core data model, a lot of things will make much more sense.

<http://git-scm.com/book/en/Git-Internals-Git-Objects>

I don't know if anyone shares my experience, but I actually found svn rather
mysterious and difficult to understand. I never actually saw the point to it
at all, so I never bothered using it (unless it was mandated by some
authority).

It's only when I understood git that I really understood what version control
is supposed to be about.

So, I think people who try to "dumb it down" by giving tutorials that ignore
the data model and focus only on the usage are not doing anyone a favor.

Git should be treated like a new programming language or a new operating
system. Spend a few days reading (or watching youtube videos) about how it
works and why it was designed this way.

Yes, you really have to understand how it works. But it's precisely the fact
that you _can_ do so, that make git the best version control system out there
in my opinion.

~~~
crazygringo
Taking a week to learn a computer utility seems insane to me, I think that's
one of the problems.

People just want some version control, they don't _want_ to learn a whole
programming language to have to do it.

Imagine if I had to spend a week learning how to configure my screensaver, set
up hard drive backups, or install Dropbox? Forget about it.

Now if git were only popular among super-power-hard-core programmers, then I
don't think there would be any criticism. But it's the fact that it seems like
pretty much everyone has switched to git now, because its advantages are
fantastic, but it takes 100x longer to learn than any other tool I've ever
used.

~~~
MBlume
Oh come on.

Your language, your editor, and your source control. Three things worth
knowing backwards and forwards if you're going to call yourself a developer.
Three things _easily_ worth spending a week grokking, if necessary.

~~~
aneth4
And then there's the thousands of libraries, debuggers, versions, deployment
choices, design strategies, etc etc. Development is an endless path of
learning, and git is barely learnable.

And editors don't take a week to learn because you don't have to learn
everything to use them. Even vi works quite well with just a few commands, and
you will never NEED anything other than those, only optimize your usage.

~~~
chris_wot
"git is barely learnable" - hardly!

~~~
aneth4
The fact that even experts admit they don't understand the array of options
and implications for commands like reset and rebase would tend to support me
here.

And there is always dispute about the best way to do something as simple as
back out a commit or clean large old files from a repository (very difficult
with a large team). The series of incantations to do such things is always
ridiculously obtuse, with non-intuitive flags and symbols.

Sure the basics are learnable, and google can often reveal solutions (though
rarely definitively), but I know no one with a comprehensive understanding of
the majority of git fundamentals.

~~~
chris_wot
I wouldn't be calling someone an expert if they don't understand what a rebase
is.

~~~
retrogradeorbit
"git reset is probably the most confusing command written by humans. I've been
using Git for years, even wrote a book on it and I still get confused by what
it is going to do at times." -- <http://gitref.org/basic/#reset>

