Git the fsck out
blog.aisleten.com
blog.aisleten.com
I don't think this has anything to do with Git. I remember the commands just fine, without having to use Google.
- On my side everything is fine - bullets are flying out. The problem is with the targets.
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 rather like the Bazaar single binary approach with inline help on commands.
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.
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.
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.
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.
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.
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.
The sideways push I get, but given that I use a laptop I find it irrelevant to me.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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....
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".