
Git is a Harrier Jump Jet. And not in a good way - MikeTaylor
http://reprog.wordpress.com/2010/05/10/git-is-a-harrier-jump-jet-and-not-in-a-good-way/
======
mgrouchy
Is this serious?

Can't commit like you expect?

    
    
        git commit -a
    

Alternatively stage a commit

    
    
        git add filename 
        #then commit it
        git commit -m "commit message"
    

worst _Git’s just version control._ As I recall version control is pretty
important to the software developer toolbox. I know its pretty important to
mine.

If it takes you that long to get up and running with Git, I can't imagine what
kind of developer you are.

Edit: I should add an addendum to this: I don't mean this as a personal
attack, I'm just kind of incredulous about all this talk about version control
is hard. I have used cvs, svn, mercurial and git and I never found them
particular hard to get up and running with them. All source control has its
pain points, but usually getting started on a project that has already been
using it, or a new project isn't one of these points.

~~~
Empact
Yeah, seems he isn't around people who know git. E.g.:

    
    
      Me: Why?  I already added them before, why do I need to add them again?
    
      They: You just do, OK?
    

The answer isn't "You just do," neither is it complicated. You need to re-add
files _after you've further modified them_ , because you aren't adding files,
you're adding changes to files at the time you added it.

After all, why should your VCS assume that your file layout consistently and
meaningfully aligns with your changes? I've found it's much more meaningful to
cut up a body of work into several commits after the fact using a tool like
GitX.

------
prosa
_Version control is hard, let's go shopping!_

Kidding aside, arguments like this just do not hold water. If the tool doesn't
fit your needs profile, use something else.

~~~
icco
I agree. Also, I use git for small projects due to it's ease to set up.
Subversion takes far too much work to just start using. I sit down, create a
folder, code in it, and git init and I have all of my code in version control.
I agree it doesn't degrade easily, but like the above comment states, if it
doesn't work, either fix it or use something else.

------
steveklabnik
Wow. Generally, I've really loved the Reinvigorated Programmer. This feels
like it was written by someone else, or is some kind of joke.

The guy who dedicates three posts to loop invariants and formal (ish)
reasoning practices thinks git is hard?

I feel like this post is from some kind of bizarro-world. Even more so since
I'm reading on my phone, so there are no sushi pictures!

~~~
eru
There's only one sushi-picture in there, and two cheesy ones of other things.
The One ring and an aircraft.

------
stephenjudkins
Using Git--for simple things--is not that hard. Seriously, it would take 10
minutes to write shell scripts that simulate Subversion's behavior if one
wanted to. It would take far less time than writing a blog post about it, even
with only a cursory knowledge of Git.

Further, the tendency of some developers to bitch about using any tool outside
their comfort area is annoying. Guess what, users of open source software:
unless you're programming using assembly, you use the tools you do because
people decided to try something a little bleeding-edge, adventurous, and new.
The idea that developers should always "stick with what works" and resist
change (even if they don't always like it) is kind of freeloading. Some day,
the tools one is using now will be obsolete for the purpose it's being used
for now. Be ready to accept change.

That said, the OP should try Mercurial if he wants something with a slightly
shallower learning curve.

~~~
davidw
Version control software, like, say, file systems, is not an area where most
people _should_ be "adventurous". They should just work, and mostly keep the
hell out of your way.

~~~
eru
And Git just works. At least on the same level as not expecting "rm -rf /" to
"read mail really fast".

~~~
davidw
It works, yes, but there is truth in what that guy says. It's fiddly, and
often not obvious.

------
jarin
I think you can sum up that article as "Git is terrible because I couldn't
figure it out."

------
subwindow
If you're only using 3% of git's facilities, then you're doing it wrong.
You're probably doing it wrong because you don't understand the other 97%.
That's OK, but don't pretend that the stuff you don't understand is useless.

Almost every time I learn something new about git, it is something that is
immediately useful.

------
habitue
Git is a harrier jump jet when you need it, and a motorcycle the rest of the
time.

It is perfect for little "6 file projects". Try getting started so quickly
like this in CVS or subversion:

    
    
      git init
      git add . 
      git commit -a -m "My own repo"
    

Bam, done. Now you can just do git commit -a whenever you need to add
something new. Sure, the index might feel strange to some people, just skip it
with -a.

~~~
kscaldef
And for reduced typing, you can even alias it in your .gitconfig:

    
    
        [alias]
          cam = commit -a -m
    

Then you can just type 'git cam "look what I changed!"'

------
rufo
Anecdotally, everyone I know who's been taught git with no prior VCS
experience has had no problem with learning it.

------
kennu
Git has certain usability issues, although this article didn't seem to cover
them. For example, previewing changes about to be pulled from a remote
repository, or resolving conflicts after a bad pull, are complex and counter-
intuitive operations.

But internally Git is incredibly simple and well designed. It just needs some
polish to make all common use cases intuitive for the casual user. The UI
should always guide the user how to proceed in unclear situations. Common use
cases should have simple shortcuts, instead of requiring 2 or 3 separate
commands.

------
wwortiz
As someone who doesn't understand version control extremely well I can say I
don't have much of a clue when it comes to CVS and all the configuring to make
it behave normally but git is extremely easy for someone who only needs a
little version control. If you don't get it read this
<http://progit.org/book/ch2-0.html> otherwise it just seems like a rant by
someone who just doesn't want to try and learn something new (over CVS).

~~~
eru
Yes. The times I used CVS or subversion were more frustrating than learning
git. Especially with all the server setting up you (used to?) had to do. And
all the warnings about never using the filesystem-native renaming tools.

Git can get complicated later on, when you are doing complicated things. But
on easy things, git is easy enough.

(And so are darcs and mercurial and the other modern version control systems.)

------
arantius
Wow. I'm surprised at the one-sided-ness of comments here at HN. I read the
article and totally agreed. I've been trying to deal with all the complexity
of working copy/index/local repostory/remote repository/other remote
repositories, merging changes back and forth, and umpteen other things, for a
good few months now. It's genuinely Hard (TM).

I _have_ definitely done occasionally awesome things, like amending commits
with small noticed typos before pushing, stashing is totally awesome, cheap
branches are mostly convenient. But there's _so many_ layers, and nothing
(that I've yet discovered) that lays it out in a manner that makes it easy to
understand.

I've a lot of past experience with Subversion. I used SVK for a while, so I
could get local dev branches and commits without pushing to the central
repository. But git continually confuses me. Plenty of it is un-learning other
VCSs (no, to get rid of that mistaken change, I don't revert the file, I
checkout the file. revert is a command but it does wholly other things.) Not
to mention the many names for things. Local, staged, cached, indexed?

Yowza.

~~~
steveklabnik
Personally, I think that git is hard to learn if you try to think of it in
terms of your previous VCS. As you say, you have a lot of svn experience, so
maybe that's the issue.

Really, at its core, git is incredibly simple. That's one of the reasons that
it's hard. It's just a DAG of changesets, and every command lets you
manipulate that graph, or give points on the graph names.

Anyway, I'd echo several people's sentiments here: <http://progit.org> is a
really good explanation, and also fairly short.

------
TrevorBurnham
I'm a recent convert to Git. Yes, it's confusing to newcomers. So is
Subversion and all the rest. I just don't think there is any version control
tool where the commands are totally intuitive, and there probably never will
be.

The good news is that as more people flock to Git, they'll create better
tools. Look at some of the wonderful things people have created for
Subversion; for instance, the beautiful Mac client Versions, which is aimed at
web designers rather than programmers. There's no reason something similar
can't be built for Git. The average user shouldn't have to use the command
line. Once those tools are in place, it won't matter how unintuitive Git's
terminology is.

------
aasarava
I don't use git but am considering it. So I was hoping this article might
point out a few things I should beware of before getting started.

Instead, all it provides is one, single, minor example of a potential issue:
you can't commit the same way as CVS or subversion.

Not sure why it took the author so many words to get around to saying that.
And if there are other problems with git, I'm not sure why the author doesn't
mention them.

~~~
ojbyrne
It's kind of laughable, because you just need to add a flag - "git commit -a"
to do what he wants.

~~~
MikeTaylor
Right. The entire article is about how you need to do "git add" before
committing.

I can tell you read it _reaaally_ carefully.

~~~
ojbyrne
Umm, my point is that you don't.

------
chmike
I found the fossil dvcs referenced in a comment interesting.
<http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki>

------
digitallogic
Buried in a bit of a rant is a very good point about using the right tool for
the job, though I'm doubtful this was the actual intention of the post.

------
bitwize
Git is a Harrier jet all right. I just got into it and keep thinking to
myself, "This thing can turn on a dime, Macross Zero-style!"

~~~
mullr
I was just thinking that maybe it's a Harrier since you can easily tilt the
thrust the wrong way and end up screwed. But you can always get back to where
you were, so perhaps it's a Harrier with a time machine.

~~~
eru
At least unless you are doing something like --force or --hard. But you should
be smelling that those commands do something potentially non-recoverable.

------
knuckle_cake
Unlearning CVS/svn is the truly difficult part of learning git.

These complaints could only come from someone who has used CVS/svn in the past
and expects git to work exactly the same way.

Are there any extant articles of someone who has never used source control at
all before having these problems with git specifically and not other SCMs?

------
thisduck
<http://book.git-scm.com/>

<http://progit.org/book/>

------
eru
Was there any genuine content in there?

