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.
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.