
Confessions of a Git Skeptic - idheepan
http://blog.artlogic.com/2013/02/14/confessions-of-a-git-skeptic/
======
lkrubner
The thing I miss most about Subversion was the involvement of the whole team.
git is only for programmers. Subversion was for everyone: our graphic
designers had no problem with it, our project managers had no problem with it,
our dumbest QA people had no problem with it. Subversion is easily used by
non-technical people. There are many GUIs for Subversion that make it drop-
dead easy to use. And there were big productivity gains to be had by having
the whole team using the version control system.

git has cut the team in 2. The graphic designers no longer know how to commit
their work, nor do the frontenders, nor do most of the project managers. In
particular, when a conflict comes up, nobody knows how to resolve the conflict
(with Subversion we had a simple rule: "If you get a conflict, save your work
outside of the project, then "accept theirs full", then re-integrate your
work. A pain, but non-technical people could manage it). Instead, all of those
people now send their work to the programmers, via email or Dropbox, and they
say "Please integrate this into the project". This increases the amount of
work that the programmers have to do.

We now use git for everything, because it seems like it is the thing to do,
and it helps the programmers merge their work together. But the price is high:
the loss of half the team, who can no longer use the version control system.

~~~
Surio
Sigh... Tell me about it! This story and small variations on this story, I
hear a lot from various sources!

> We now use git for everything, because it seems like it is the thing to do,

You nailed it. And IMO this current obsession with Git/Github is bordering on
unhealthy. I really wish/hope this fad dies out fast!

~~~
owenjones
What about it is unhealthy and what about it is a fad? What do you wish/hope
to replace Git with?

Also anecdotal, but the graphic designers at our company have no problem using
Git.

~~~
TylerE
Mercurial?

So much easier conceptually, the cmd line utility was written for actual
humans, and it has sequential commit numbers.

~~~
ekimekim
Sequential commit numbers? How does that work with branching? Or other
people's commits? eg. I commit #100, you commit #100, you pull my commit, now
we have duplicate identifiers.

Git commit ids are a hash of the commit content. This has very nice properties
in that:

\- Ids are duplicate if and only if the commit is identical (the collision
chance is so low it's not worth considering)

\- It's content-addressable

And you can refer to it by any unique prefix, so it's not a pain to type out
(and you should only rarely be typing out particular commits instead of
branches or tags).

~~~
lucian1900
Mercurial has local sequential commit numbers. The hashes are of course what
one must use when others are involved.

------
lloeki
> _Perhaps my eureka moment is still to come._

The eureka comes when you stop using git by retrofitting Subversion workflow
on it. The _"Git forces me to learn obscure things"_ part precisely shows
that.

The hardest part is not learning "obscure" git things, it's unlearning the
habits and preconceived ideas about how SCMs work.

~~~
Lewisham
Yeah, I think this is the killer, and it's been my experience teaching Git to
others. SVN does have a mental model that makes more sense: there's my copy,
and there's the server copy. When I finish, I make the server copy look like
mine. Done.

The terminology used by Git makes things hard for people to understand, remote
and local, branches here there and everywhere. The OP is right that the
deletion syntax for branches is awful.

BUT

It's not magic. It's explained all very easily.

"The staging area lets you batch up your changes so you can issue multiple
commands to add files, or get rid of them if you change your mind."

"Just use `git pull`. If you don't know why you need to `fetch`, don't do it.
Git pull is just like an SVN checkout."

"When you commit, you don't have to send it to other people, so your work can
be in a broken state, and you won't break it for everyone else. When you're
super happy with it, use `push` and it'll be visible to everyone."

These explanations get people who understand SVN to get Git, and they
understand exactly what Git is providing over SVN. Once I use these
explanations, people never seem to have problems.

What seems to keep happening is they look on the Internet for solutions to
issues, which tangles them up even further, with rebasing and such. Even the
simpler tutorials like learn.github.com are obsessed with showing pictures of
trees and different branching states that beginners simply shouldn't be
exposed to. Their mental model is completely screwed up, and they start to
blame Git (not unreasonably) rather than themselves. When SVN screw ups
happen, they blame themselves because SVN is conceptually simple, so they know
the mistake must have happened with them. Then I hear things like "This never
happened with SVN" or "SVN was always so much easier". When I prod them about
this, they do end up remembering that SVN had it's own issues, but they forget
them when their current problem is Git.

EDIT: Oh, and the other problem is that some of the GUIs out there are
criminally poor. Particularly eGit for Eclipse. It exposes a metric crapton of
functionality that I have absolutely no idea about, and I've been using Git
happily for two or three years now. I don't know about refs or anything, and
eGit makes it all exposed and seriously painful to do anything. Having tried
to help someone with it, I gave up. "I use the command-line. You think I use
it because I am clever, but I use it because I am stupid. The command-line is
much simpler than this car crash, and I have no idea how you have got as far
as you have with it."

~~~
NateDad
This.

------
mpyne
I don't even get to code that much and I've found very compelling reasons to
do all of:

\- git rebase -i (the "cleaning" of history)

\- git add -p (which requires a separate staging area)

\- Using a bare repository (which, just for the record, I've _also_ had to do
with SVN, but we didn't have a special Googlable term for it)

\- Track the difference between a local and remote branch (this is actually
inherent to DVCS workflow, it's like going from DOS to UNIX and complaining
that they make you track file permissions... you didn't even have the _option_
on DOS!)

It's actually kind of embarrassing to see an SVN user claim that they don't
understand the difference between a downstream concept of a central repository
and the remote concept of the same repository, because I can sure as hell
remember having to run "svn up" before "svn ci" just in case someone had made
a commit to the remote repo in between the time of my last update and my
upcoming commit.

master, "origin/master", and origin's own master all have corresponding
concepts in SVN, even if master and origin/master had to be the same by
definition.

One more thing: I'm pretty sure SVN now has only one .svn directory, just like
git.

~~~
manojlds
> I'm pretty sure SVN now has only one .svn directory, just like git.

That was a more recent change in 1.7.x ( around late 2011?) and I know people
who are still, in 2013, in 1.6.x

------
slurgfest
Coming from svn, the skepticism here is really about distributed version
control, and being heavily involved with the vcs at all. (Being heavily
involved with svn, like setting it up and administering it well, is really not
that easy compared to just using git, what's easy is just jamming stuff into
svn, as long as there are no conflicts).

Having a local repo and push/pull to any other repo is not a complication but
a huge advantage. It lets you do things like commit while you are on an
airplane, or share committed work in an internal team before pushing to trunk,
or keep repo history even if the server dies in a fire. It lets you not have
to worry about who can be trusted with commit permissions or not. Being able
to commit all the time without pushing lets you keep revision history without
checking in, so you don't end up with many copies of your working directories,
or saving up changes before you are 'allowed' to commit.

Since you can commit all the time, you can destroy the working tree trying
things out and then bring it back if they didn't work.

So let's not complain about having a working tree, local repo, or remote repo.
The staging area makes it so that you don't have to complete all staging of
many different files in one huge command. You can add/rm something, preview
what's staged, and only commit when you are satisfied.

In addition, CVS type merge is a pain while it is actually much simpler with
git or hg. And being able to keep rebasing your private feature branch on a
changing remote branch is a huge improvement.

------
pkulak
All I remember from our SVN days was the constant disasters. It seemed like
everything you tried to do more complicated than changing a couple lines would
put the whole system in some horrible state that required gross things exactly
like what this article was talking about (coping directories back an forth).
And then, all that directory copying would just as likely make everything
worse because the 400 little .svn directories were no longer consistent. Good
riddance.

------
jayferd
I'm not sure what you mean by "we maintain extra repositories on a staging
server for deployment". What exactly are you doing, why is that necessary, and
what extra steps does it involve?

The "extra steps" (the index, remote branches, etc.) are there for a reason,
and that reason is to give you the tools to be careful with your codebase.

I always use `git fetch`, for example, because unless I've been doing
something reeeeally weird, `git fetch` _will never touch my local work_. At
all.

The index allows me to make sure I know _exactly_ what I'm committing, and the
extra step gives me the chance to look over it once again before I commit.
(`git add -p` and `git commit -v` help a ton here, even though it feels like
they "slow things down"). I never have "Oops, I didn't mean to commit that"
moments anymore.

And the merging model (yes, with those opaque commit-hashes and mutable
history and 3 kinds of branches) allows me to fix things when I screw up (or
one of my coworkers does). Which still happens all the time, because we're
human.

I think you could get a lot more out of git if you were willing to invest the
time to learn more about its branching model (which really is elegant once you
understand it), and to configure it properly. Otherwise, you may have a look
at Mercurial, which has a more svn-like experience.

~~~
brown9-2
It almost sounds like they push the repo to the staging server rather than
pull from a central repo to the staging server.

------
hcarvalhoalves
The benefits of DCVS, and Git in particular, are pretty clear, specially as
you scale the team size.

Git's command line is a UX train-wreck though. Poor consistency, learnability
and leakage about how the internals work. I think Git gets a lot of
unnecessary flak because even though people realize it's superior, they are
always fighting it into doing what they want.

My pet project is giving it a saner command line.

~~~
shubber
DCVS is a fantastic advance. Git isn't the best example of that, though. IMO,
the UX problems of Git have everything to do with its internal model of
revision history, not the structure of the internals. But I still pine for
<http://monotone.ca>

~~~
hcarvalhoalves
I would say the UX problems of Git have everything to do Linus writing it for
himself.

------
pseut
This quote is priceless:

> Git allows the topic-branch development style, where you maintain one short-
> lived branch for every task you work on. Like many people, _I learned about
> this style from distributed version control. I love it. It’s an excellent
> way to switch between tasks, and maps well to the way I actually think about
> the state of the project._ But you don’t need Git to do this! Subversion has
> “svn switch”. _It does have an annoying problem that if you specify the
> wrong URL to switch to, it will trash your local copy rather badly._
> However, Subversion seems to have fixed that problem in version 1.7.

Quite an annoying problem. I'm not really sure why the author is a git skeptic
if it enables and introduced him or her to a wonderful workflow.

The ability to _easily_ work on multiple branches and make offline commits is
a huge selling point for any DVCS. I really like git rebase and git add -p now
as direct arguments for git, but wouldn't have used them right away.

Edit: added clarification after quote

~~~
javert
> I'm not really sure why the author is a git skeptic if it enables and
> introduced him or her to a wonderful workflow.

Perhaps because you can do the same thing in SVN?

At least, that's what he says. I don't really know SVN.

~~~
ambrice
You could do topic branches in SVN, it would just be painful. It's sort of
like saying "Why use C++? You can do object oriented programming in C with
structs and function pointers."

~~~
csense
Actually, I like to avoid the bloat of C++ and just use "object-oriented" C
with structs and function pointers wherever possible.

This is largely due to the fact that I have a strong aesthetic preference for
languages where you can hold most of the language [1] in your head. Such
languages are called _compact_ [2].

[1] Compactness of _language_ and _standard library_ are different. Having a
non-compact standard library isn't necessarily a bad thing, especially if it
means I don't have to complicate my life with third-party libraries.

[2] <http://www.catb.org/esr/writings/taoup/html/ch04s02.html>

------
iamwil
Git does have a high learning curve. And the command line tools are opaque,
even to developers. Also, it forces you to have a mental model of the
underlying implementation to know how to use its tools.

But underneath, the concepts are pretty simple, and because it's the right
simple concepts, the things you can do with it are pretty flexible, and thus
powerful.

Git's interface can defn be way better for the default case. But everyone and
every team's workflow is different, so the inherent flexibility will always
involve a little bit more complexity.

And oh, it seems that he hasn't yet discovered selective commits or stashing,
so staging seems like an extraneous extra step.

And rewriting history seems frivolous if you work by yourself. But it makes
pull-requests on open source projects way easier to manage if your commits are
clean. And if you need to rollback to a working version of your production
code, it helps to have clear commits too.

~~~
homosaur
"it forces you to have a mental model of the underlying implementation to know
how to use its tools."

This is a BIG reason why I recommend even to advanced Gitsters to use a GUI
tool like Tower or SourceTree so they don't get confused or inconsistent about
how their repo is structured. I've used Git for years and I can't keep it all
in my head. Surely some can but not me and probably not most.

------
hobbyist
Once speaking to a freebsd developer, he explained the problems with git in
freebsd workflow.

His explanation was on the lines that if there are 100 developers working on
different trees of freebsd and they want to commit their work, it causes a
race, as if some one commits before you, you need to do a git pull,
incorporate changes and then push, even when they are working on unrelated
components.

My response to this was yes, and that is why git allows you to create branches
so cheaply, but he still was not convinced.

~~~
pseut
I like rebase for this rather than merging the changes. But it's kind of
strange to think of it as a problem that you'd need to acknowledge the other
developers' work before committing...

~~~
hobbyist
Well, if 2 people are working on different files, they can commit their
changes to svn without updating their local copy first. But in git you have to
bring your copy to the same revision as the remote one, in order to push your
changes, irrespective whether the changes you made our conflicting

------
lucian1900
You sound like you'd like Mercurial. Give it a try.

~~~
emn13
This. Though mercurial has it's own set of issues, and it doesn't mitigate the
DVCS problems with maintaining extra repos (e.g. you still have many more
steps in your workflow than in SVN, and you still don't have nice short,
ordered, global revision numbers).

~~~
makeramen
Not global rev numbers, but it does have them. Once you understand the
"distributed" part of DVCS, I think that's an OK tradeoff.

------
neya
I've developed a couple of Open Source stuff and I wanted to push them online.
In my old company, they used SVN for almost everything (even Graphic designs,
sometimes!) and hence I kind of knew SVN pretty well. I wanted to give GIT a
fair trial, just to make sure I don't miss out something good, out of the
personal bias in favor of SVN. And hence, I read some books, documentation and
several other resources just to learn this GIT, simply because I saw it was a
popular choice amongst many communities, including HN.

My thoughts in this entire learning process was along the lines of - "Why the
hell are they doing it like _this_ , instead of _that_? Why are they calling
_this_ , like _that_ , instead of just calling it what it already is?"

In my experience trying to learn GIT, I was able to conclude that GIT
introduces a LOT of terminologies, and concepts, making the path for beginners
like me more and more difficult. Whether spending hours learning these
concepts just to get your stuff synced properly depends on your scenario. But
for me, SVN rules.

Also, there is another REALLY brilliant way by which SVN helps me. I use
Tortoise SVN. I have a couple of external 1tb hard-drives to back-up my code.
I like to take regular backups (obviously) because some of the code is in
production and I just want to play it safe. Using SVN, on windows, I run an
SVN server on my machine, and create respective repo's on my hard-drives and
just update them and voila - I have all the code properly backed-up and
versioned. You can also automate this (there are scripts to do them), but for
me, I like to keep it synced manually. And also, you can keep your stuff
backed-up to your Google drive by making a repository inside your drive
folder. I can't imagine typing all these as commands in GIT.

~~~
ekimekim
Once again, it isn't fair to compare an SVN GUI to the git command line. Try
some of the many git GUI wrappers and come back.

~~~
neya
I've tried the official Github Windows GUI interface and still found it fairly
confusing.

------
lmm
I find the speed alone is worth it. Git lets me commit and branch without
having to think about it, without having to enter the command and then pause
for a while (even a couple of seconds is enough to break my flow) while it
does its stuff.

~~~
pseut
Definitely; I used bzr for years before using git and always thought, "how
much faster can git really be?" Startlingly faster.

preemptive disclaimer: I haven't used bzr for years and understand that it's
faster now than it was. I liked bzr. blah blah I really don't want to start a
flame war/pissing contest. But people should try git out before dismissing its
speed as a worthwhile advantage.

------
asdffdsa33
You keep saying "_the_ remote repository".

_The_ git repository is right there on your computer.

~~~
Mordak
This.

The OP says he is waiting for the git epiphany. The epiphany is that there is
no _the_ remote repository. You can use git like it's subversion, and
designate one repo as _the_ repo, but because git isn't designed this way it
isn't going to help you much in this endeavour.

------
Someone
_"I hate those .svn directories: they give me false positives when I’m
searching my files, and it’s pretty easy to mix two incompatible working
copies accidentally."_

Subversion got rid of those directories in version 1.7
([http://blogs.wandisco.com/2011/10/11/top-new-features-in-
sub...](http://blogs.wandisco.com/2011/10/11/top-new-features-in-
subversion-1-7-wc-ng-pristines/))

Also, for the searching problem: betterthangrep.com. The reason I have perl
installed on the Windows box at work.

------
porker
I feel your pain. It's not uncommon. I've managed teams using Git and consider
myself mid-level using it, but give me a month without using it and I forget
the sequence of commands (each with flags) I have to type... something that
_never_ happened with SVN.

I appreciate Git and hate going back to SVN when clients demand, but I'm
convinced it takes a certain kind of brain to feel comfortable with it.

------
DavidPlumpton
I love Git, but a workmate of mine pointed out an interesting deficiency.
During a merge from a branch some time in the distant past he said, "Hang on,
who created this branch and when? I can't even tell." It would be nice to have
a feature (even if optional) so that branch creation was recorded somewhere
(similar to notes, perhaps).

~~~
homosaur
I like optional, it seems like there's no reason there couldn't be an
additional flag set at the time of branch. You do kind of know who branched
though because aren't they going to have the first commit on that branch? But
perhaps what you'd be looking for is something like the tag system where one
could bring up all the branching at once in a big list...

------
natmaster
You'll probably like Mercurial better. However, the race has basically already
been won by Git. I wish Git would be less confusing while still keeping its
power. None of its terminology is intuitive, so you must spend a lot of
unnecessary time learning git specific jargon to use it effectively.

------
kibwen
Good points, but I want to elaborate on this:

 _"You can use “pull” to mean “fetch and merge”, but some authorities will
advise you not to. You can also use “commit -a” to avoid the “add”, but you
still have to be aware of it."_

Whatever tutorial I originally used to learn Git made use of `git pull` and
`git commit -a` exclusively, without any elaboration. It wasn't until long
into my Git career that I was even aware of `git fetch` or `git add`. To this
day I use `git add` only occasionally (but it's _so useful_ when I do need to
use it), and I honestly can't think of a case where I've needed `git fetch`.

I'm about to teach my co-workers to use Git for a project I'm spearheading,
and I intend to expose them to this simplified view and let them fill in the
blanks when needed.

------
csense
Having separate add and commit steps has improved my workflow.

If you do an add, followed by a "git diff --cached", you can view what's going
to be committed before you do the actual commit.

I've found this workflow to be useful, since it helps see things like
debugging print statements that crept in, or unnecessary files accidentally
added ("git diff --cached --stat" is useful for the latter).

------
silverbax88
"Git adds extra steps to the flow of content between your local files and the
remote repository. "

This is the biggest issue I've always had with Git. I've struggled to
understand why so many developers swear by a system that takes several steps
backwards from other systems.

~~~
ekimekim
All those extra steps have a purpose, all those extra steps can be glossed
over if you don't care.

git add is never needed if you always git commit -a

if you don't care what git fetch && git merge does, just use git pull

The biggest problem with learning git is that all git experts love to talk
about the advanced workflows, but all the beginners just want to be able to
push and pull.

------
rip747
the only thing i hear about members of our team missing from svn are using
externals. one of our members would create an external in his current client
project to our open source repo. now while working on his client project, if
he encountered a bug in our open source project, he could fix and test in the
client project, but the change would get committed to our open source project.

while git has submodules, they no way near have the flexibility of externals.
if git would incorporate the idea of externals, I think it would cure quite a
few people's complaints.

