
Git the fsck out - tortilla
http://blog.aisleten.com/2008/11/23/git-the-fsck-out/
======
jrockway
_But, every single time I want to do something, I have to look up a whole slew
of commands. Why can’t I just memorize them? Because they’re horribly arcane
and obtuse._

I don't think this has anything to do with Git. I remember the commands just
fine, without having to use Google.

~~~
DenisM
So a Microsoft engineer is drafted to the army. On the shooting range he can't
hit the target at all. When sergeant notifies him of zero hits, the engineer
puts his finger into the rifle's barrell and pulls the trigger. His finger is
ripped off. After evaluating the finger engineer turns to the sergeant and
says:

\- On my side everything is fine - bullets are flying out. The problem is with
the targets.

~~~
jrockway
That's a nice story, but it doesn't apply here. The guy who wrote the article
is just dumb.

------
DenisM
Many of the comments here and on the blog itself are perfect demonstrations of
developers' disdain for usability and oridnary users. "Is it hard to use?
Works for me. Man up and study, Nancy!". Good grief.

~~~
tdavis
Version control in general is not _meant_ for "ordinary users"; it's for
developers. I mean, sure, it can serve as a versioning system for just about
anything, but it is overwhelmingly used for code. Git doesn't need to be easy
for my Dad to use because he has no use for it.

Despite having lived partially on the command line for nearly a decade now,
there are still commands that are simply not intuitive to me. This isn't the
developers' fault, it's my fault for not becoming more familiar with the
commands and _understanding_ why they actually make sense.

 _find $directory -type f -name ' <asterick>' -exec mv {} $directory2/. \;_

If you want to move thousands of files and can't use a single _mv_ command,
something like this will work. Most of it makes sense to me, but what's with
the _{}_? That doesn't seem intuitive. And what about the extra _/. \_ crap? I
would never think to add that junk and without it (iirc) the command returns
some esoteric error.

I'm sure if I read the proper manpages, I could figure out what purpose those
seemingly extraneous symbols serve.

~~~
DenisM
As others mentioned, cvs is not just for developers, it's also for doc
writers, lawyers, UI testers and designers. All that goes into a product must
be versioned.

But fine, let's say it's for developers only. Did you notice that the article
is written by a developer? Clearly GIT is too difficult for some of its core
aduience - developers.

Blaming the user is not the way to build something people want.

~~~
tdavis
Yes, _some_ , but not _most_. I switched from Subversion to Git myself a
couple months ago and it took a week or two, but I learned "the git way" of
doing things. Yes, I would need to look up the command to remove a remote
branch, but I haven't done it in weeks and didn't commit it to memory the
first time so that's understandable.

Building something people want doesn't really need to be a goal of open-source
software. Most software is built in the first place to solve a need of the
person or people building it. Since they're not getting paid, what do they
care if everybody wants to use it? A large majority of people seem to like
Git. There will always be those who do not and I'm sure _everybody_ has
something they dislike about it. The difference is, Git is not commercial
software, so making it more usable need not be an overwhelming goal --
although, you could fork it and make it your goal.

------
qhoxie
His problems seem to be directed more at GitHub and Unfuddle than git itself.
Things like deleting a remote branch are not especially esoteric, so it seems
like he just has trouble adjusting to the new way of thinking in git. That is
fine, but his assessment of it is about as far from objective as possible.

------
run4yourlives
I'm still not understanding the big fuss about git. Okay, distributed source
control is wonderful for OSS communities, but I'm not really seeing the point
for a proprietary piece of software built by a small team.

Perhaps I just don't understand source control enough, but the fact remains
that for me, svn has never really given me any want, really. There's just no
reason for me to change.

~~~
jbert
The major win is that a DVCS decouples the "commit as save work-in-progress"
from the "commit a carefully polished jewel of a changeset which will live for
eternity in the revision history".

i.e. you can commit locally frequently, and push refined changesets upstream.
The best of both worlds.

Other top benefits include sideways pushing (work on desktop A & B, push work-
in-progress between them without polluting the central repo).

Yes, you can get a lot of the DVCS benefits from giving people personal,
scratch brances in a central CVS, but for various social and technical reasons
that seems to rarely happen.

~~~
run4yourlives
I suppose that's where I just don't understand things: What benefit does
committing locally bring? Why not just not commit at all until you have that
"carefully polished jewel"? Unless of course you're working on a change large
enough to justify it's own branch, in which case the point is moot.

The sideways push I get, but given that I use a laptop I find it irrelevant to
me.

~~~
DarkShikari
Because you no longer have to think much before committing. You don't have to
spend hours reviewing the code and having others look over the patch before
you push it to the main tree: you can just commit it locally and go work on
something else.

Then, later, you might get an idea on how to improve your previous change. You
go and amend it. And so forth. Eventually, you have a set of changes that's
ready to be committed and which you have _used locally for long enough that
you can tell it doesn't break anything obvious_. Then, you go through the code
review, and finally push the changes.

With a completely centralized system, you have one of the following going on:

A. You don't actually do code reviews before pushing changes, and trunk is
broken half the time.

B. You wait all the time on your changes being reviewed, and you can't commit
them until they have been.

C. You revert to tarballs and diffs for dealing with different changesets.

I was forcibly pushed into using git from svn, but now I'd never go back: its
simply _so much easier_ to say "OK, I'm done with this change, I'll commit
it!" and not have to wait for everyone else to be in the
office/online/available to look at the changes before I do so.

This is especially important when dealing with separate changesets that
necessary depend on each other, where you can't merely make a new branch for
the new change because it requires the old changes.

~~~
run4yourlives
Thanks for the reply. That certainly explains some clear benefit. That's the
first time somebody's laid out for me in that fashion.

------
makecheck
It would seem that some of these git "problems" can be solved the way you'd
automate anything else in Unix...write your own scripts or aliases.

Tools are not _supposed_ to please everybody. (They can't, since for every
person who loves the default configuration, there will be someone who
doesn't.)

If you can't remember that "foo -bar -baz -squareroot4515" is the command to
do X, then make a shell alias or a script that performs these steps for you,
and call it whatever you want.

~~~
cosmo7
I think the point of the article was that he shouldn't have to edit his _ssh
settings_ to use Git.

~~~
KirinDave
And he doesn't have to. ssh-keys is just a convenience.

Most of the complaints in this article can be restated as, "I haven't taken
the time to understand my version control system and so every little thing I
do is foreign and strange. Therefore I am resentful." With the multiple-user-
account issue being more of a github logistics than anything else (if you host
your own repo, you have the entire unix permissions model is available to
you).

Everyone knows git is weird and new and has a much more complex interface than
SVN, but the tradeoff is that you get an extremely powerful and flexible
version control system.

~~~
DenisM
>> "I haven't taken the time to understand my version control system and so
every little thing I do is foreign and strange. Therefore I am resentful."

It seems to me you look down on such opinion? That's what usability is about -
make things easy enough to learn so that users are not recentful.

~~~
KirinDave
>> It seems to me you look down on such opinion? That's what usability is
about - make things easy enough to learn so that users are not recentful.

We're software engineers. It is our _job_ to understand more complex software
models. Git's usability isn't terrible, it is just a more complex model that
requires a more thorough understanding of the underlying principles. And given
how trivial it is to find and read such data, my sympathy is limited.

What's more, git's usability is a radical improvement path. Between services
for remote repos (like github and gitorious) and better and better command
line tools (GitX, for example). At some point you have to bite the bullet and
_understand_ your tools.

We're seeing a lot of this reluctance in the industry as people are forced to
confront distributed concepts.

~~~
timr
_"We're software engineers. It is our job to understand more complex software
models. Git's usability isn't terrible, it is just a more complex model that
requires a more thorough understanding of the underlying principles."_

My job is not to spend time understanding how to use the version-control
flavor of the week -- my job is to write software.

You may not realize it, but you're advancing the usual, dressed-up, _ad
hominem_ attack of the perspective-challenged nerd: _"tool Y is EASY if you
just try to learn it!"_ (the implication being that if you don't want to spend
time on a yak-shaving expedition to learn tool Y -- when tool X works just
fine -- then you're lazy, dumb, or both.)

Version control is a tool. Good tools let me do my job and get out of the way.
Bad tools force me to spend a lot of time "understanding" them before I can be
productive.

~~~
moonpolysoft
So I guess that most programming languages would qualify as bad tools to you
then? Seeing as how they force you to spend a lot of time "understanding" them
before you can be productive.

~~~
timr
My job isn't to learn version-control systems. Time spent learning a
programming language is a direct investment in productivity; time spent
learning a version control system is, at best, a required distraction.

~~~
KirinDave
Your job is most certainly to maintain a working and current toolchain. This
includes programming languages and the tools that produce software in tandem
with you. This isn't just for your employer, it's for the sake of your own
career. Or do you _want_ to be like those poor men who came before us, knowing
and learning only COBOL, who now complain that software engineering is a young
person's game?

If I interview a software engineer and they don't know how to use a version
control system and actively express disdain for the concept of making sure
that the progress of development is captured, then I would not recommend we
hire them. Anyone who's had git-bisect save them a huge effort locating a bug
would probably feel the same way.

Version control is every bit as important as your editor, debugger linker, and
binary examination tools. If you don't know how to use them, you're not ready
to start playing the game on a professional level.

You might say that I'm using Ad Hominem here, but I don't feel it's that way.
There are minimum standards for software engineers who want to develop
software professionally, and using version control and understanding why we
use version control is pretty high up on the list. If a basketball player
isn't ready for the NBA, it isn't Ad Hominem to tell him his game needs more
work, even though he may feel very insulted by the concept.

~~~
timr
_"Your job is most certainly to maintain a working and current toolchain."_

Subversion works. It's well-documented, simple, and there are many tools that
work with it. Tell me why it's an inappropriate choice for a "working and
current toolchain".

 _"There are minimum standards for software engineers who want to develop
software professionally, and using version control and understanding why we
use version control is pretty high up on the list. If a basketball player
isn't ready for the NBA, it isn't Ad Hominem to tell him his game needs more
work, even though he may feel very insulted by the concept."_

Not wanting to learn the version-control flavor of the week is a very
different thing than not knowing how to use version control -- and it's
suggestive that you've so confused the two concepts. To extend your basketball
metaphor, version control software isn't part of the _game_ , but rather, a
piece of the _equipment_. If you suggested that an NBA player should spend
even a day "learning" how to dribble with a new type of ball, he'd laugh you
out of the room -- _unless_ that ball added a significant advantage to his
game.

Being a professional is more about judicious decision making than it is about
raw knowledge of technology. The transition of a pre-existing project from
Subversion to Git adds huge complexity, in exchange for very little, as far as
I'm concerned. When the situation changes, and Git adds more value than fad, I
will re-evaluate.

~~~
KirinDave
_"Subversion works. It's well-documented, simple, and there are many tools
that work with it. Tell me why it's an inappropriate choice for a "working and
current toolchain"."_

Because it is not a distributed version control system. As more and more
people use a dvcs, they realize how incredibly flexible, useful, and generally
more powerful it is vs. a centralized vcs.

There is clear value added on numerous levels over subversion. You simply
haven't bothered to research it.

 _"Not wanting to learn the version-control flavor of the week is a very
different thing than not knowing how to use version control -- and it's
suggestive that you've so confused the two concepts."_

Git is not a flavor of the week. It is emerging as the dominant contender
after literally 2 years of fighting and evolving for superiority within the
dvcs community. This field is not new. It's suggestive of how out-of-date your
information is that you aren't aware of these.

 _"Being a professional is more about judicious decision making than it is
about raw knowledge of technology."_

Yes. And I'm directly saying that you're making poor professional decisions.
DVCS isn't fad anymore, it's the new standard.

------
ohhmaagawd
we just started a new project and we tried out git briefly. our prob with git
is it supports ssh auth only (not HTTP Auth), which is retarded. makes setting
up new users a pain. and leading non-techies thru setting it up is quite a
challenge.

the other major prob is lack of windows support.

the people coding git clearly don't care about average joe users, just unix
geeks.

don't forget, there are a lot of people who use source control that have never
opened a command line in their life (like designers, doc people).

Because of these issues we had to switch to subversion....

~~~
epall
And Subversion is perfectly appropriate for your uses! TortoiseSVN is a snap
to use (and it's not the only great svn GUI out there), and Subversion seems
to make sense to people. The only reason I see to use git is if you're trying
to keep a bunch of developers who are running off in different directions to
maintain a somewhat coherent codebase. Or if developers want their own
playground. Even then, though, I worked at a company that used centralized
Subversion, but almost every developer used git-svn locally. Different tools
for different applications!

------
thwarted
It seems you could replace all occurrences of subversion with cvs and all
occurrences of git with subversion and you'd have a blog post you could date
2001.

~~~
gjm11
Um, no. Because the specific complaints the author is making about git
(compared with svn) aren't in fact ways in which svn is worse than CVS.

If you didn't like Subversion (and preferred CVS) in 2001 it was because it
was too new, because you'd heard scary stories of repository corruption,
because you didn't like having a single revision number for your whole
repository, that sort of thing.

The only one of those that's at all parallel to any of what Micah is saying
about git is the last one.

Now, sure, both Micah's complaint now and an anti-svn complaint in 2001 fit
the template "There's this cool new thing, and I'm not convinced it's an
improvement on its predecessor". But, guess what, Micah said more than that,
and the actual point is in the specific complaints he made, not in the fact
"someone thinks something isn't better than what it's allegedly a better
replacement for".

