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.
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.
That you can remember how to do something is not an argument for that being the best way to do said something, or even a good way to do it.
The only good arguments for not making things simpler are "they cannot be any simpler", closely followed by "the tradeoffs aren't worth the effort/cost".
Why not simplify everything, where possible? It's not about dumbing down, it's about being able to do more in total because each step is easier.
I think there is a lot to be said for intuitive tool design. While the article was particularly single sided, for something you should use as much as version control it should be low barrier.
I rather like the Bazaar single binary approach with inline help on commands.
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.
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.
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.
The '{}' is where 'find' substitutes the filename into the '-exec' expression.
The '/.' is pointless but harmless, conservative ass-covering, likely because the author was burned by leaving off a trailing slash before. They're already restricting types to files anyway!
The semicolon terminates the -exec expression, and has to be escaped with a backslash so that the shell won't interpret it.
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.
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.
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.
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.
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.
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.
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.
How about working on your own laptop, committing changes locally, fixing wrong/broken commits, and then seamlessly merging your changes with others. It is also much faster (e.g. try using svn blame), stores all the history locally, makes working on different branches very, very easy, etc.
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.
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.
>> 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.
"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.
No one is telling you you have to learn how to use the version-control flavor of the week if your project doesn't currently use it and your project is serviced just fine by some other version control flavor that everyone is already familiar with and is productive using.
However, it's isn't very productive to have to deal with the same problems every day when using tool X, especially if taking a few hours to learn tool Y and switch to it would solve those problems.
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.
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.
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.
"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.
"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.
I guess the question is which part of the learning curve is there for a reason and which part is preventable.
Someone has already asked the question - is Mercurial any less powerful for being easier to use?
I am sitting on the sidelines (svn) and waiting for the dust to settle. My only interest is to have one dcvs emerge with all the best in it that this field can offer.
Mercurial is marginally less powerful (it's maybe 6 months behind git in features, perpetually). This is not a deal-breaker (except that I don't like Mercurial's equivalent of cheap local branches, these patch queues are just an awkward model for thinking about it), but then there is the speed issue. Git is incredibly fast, so fast that you almost never notice it working even for massive amounts of data.
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....
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!
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.
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".
I don't think this has anything to do with Git. I remember the commands just fine, without having to use Google.