I don't know if anyone shares my experience, but I actually found svn rather mysterious and difficult to understand. I never actually saw the point to it at all, so I never bothered using it (unless it was mandated by some authority).
It's only when I understood git that I really understood what version control is supposed to be about.
So, I think people who try to "dumb it down" by giving tutorials that ignore the data model and focus only on the usage are not doing anyone a favor.
Git should be treated like a new programming language or a new operating system. Spend a few days reading (or watching youtube videos) about how it works and why it was designed this way.
Yes, you really have to understand how it works. But it's precisely the fact that you can do so, that make git the best version control system out there in my opinion.
Taking a week to learn a computer utility seems insane to me, I think that's one of the problems.
People just want some version control, they don't want to learn a whole programming language to have to do it.
Imagine if I had to spend a week learning how to configure my screensaver, set up hard drive backups, or install Dropbox? Forget about it.
Now if git were only popular among super-power-hard-core programmers, then I don't think there would be any criticism. But it's the fact that it seems like pretty much everyone has switched to git now, because its advantages are fantastic, but it takes 100x longer to learn than any other tool I've ever used.
> Taking a week to learn a computer utility seems insane to me
I teach git at work. It takes me a grand total of 10 minutes to explain git's core concept to any dev. It takes me the better part of one hour to teach them how to use git. It takes them the rest of a work day for them to train basically without any intervention on my part, only man pages and a bunch of questions. After that they're basically without training wheels and hardly reach to me, except for the trickiest cases. That's assuming no one is stepping on the brakes, then one who does not want to learn, won't learn.
Your language, your editor, and your source control. Three things worth knowing backwards and forwards if you're going to call yourself a developer. Three things easily worth spending a week grokking, if necessary.
And then there's the thousands of libraries, debuggers, versions, deployment choices, design strategies, etc etc. Development is an endless path of learning, and git is barely learnable.
And editors don't take a week to learn because you don't have to learn everything to use them. Even vi works quite well with just a few commands, and you will never NEED anything other than those, only optimize your usage.
The fact that even experts admit they don't understand the array of options and implications for commands like reset and rebase would tend to support me here.
And there is always dispute about the best way to do something as simple as back out a commit or clean large old files from a repository (very difficult with a large team). The series of incantations to do such things is always ridiculously obtuse, with non-intuitive flags and symbols.
Sure the basics are learnable, and google can often reveal solutions (though rarely definitively), but I know no one with a comprehensive understanding of the majority of git fundamentals.
"git reset is probably the most confusing command written by humans. I've been using Git for years, even wrote a book on it and I still get confused by what it is going to do at times." -- http://gitref.org/basic/#reset
source code management is way beyond 'a computer utility', but since you brought it up, here are some other computer utilities:
- dd
- bash
- find
Most of those require quite a bit of time to master.
Now, moving past that, git isn't merely a computer utility, its a foundational element in programming. It's actually more primitive than a programming language itself! The thing that separates the high school students from the "professional" programmers is SCM, and mastery of it. Having seen hardcore dev done on 10m loc code bases in perforce, you need some perspective on how hard git is and isnt.
One of the biggest problems I find is that people attempt to understand git via the lens of SVN. Once you free yourself from the past and understand the basic fundamentals of git, and cast aside your svn-isms you will be zen.
I for one wouldn't hire a developer who isnt intimately familiar with at least one SCM system. Zip files named v1, v2, v3 anyone?
But you aren't going to sit down and spend a week learning all the ins and outs of dd, bash, find, or, say, grep. You are going to skim the docs, learn the minimum to do the task at hand, wash, rinse, and repeat.
My path at learning SVN was that way too. Heck I didn't even learn the merge command for a couple years until I really needed to, and then I realized how much I had been missing.
I think the big issue that some of us have with git is it can't do all the same things that svn can do. Of course a big problem with svn is it can't do all the things git can do. I wouldn't set nails with a ball peen hammer either.
What do I do if a merge fails? How do I abandon the merge (git certainly doesn't help you, it just keep complaning that there is an unresolved merge).
Why do I get 'git push' telling me there is nothing to push, but 'git pull' telling me I have branches with resolved merges (because git push pushes only one branch, and git pull pull everything).
Those are just two things I've seen beginners hit recently.
Following the rest of the discussion, at those points you do what you do with any other tool you use: pop into the manpages for two minutes and figure it out.
Before applying outside changes, you should get your own work in good shape and committed
locally, so it will not be clobbered if there are conflicts. See also git-stash(1).
git pull and git merge will stop without doing anything when local uncommitted changes overlap
with files that git pull/git merge may need to update.
How do I abandon the merge?
From the man page of git-merge:
--abort
Abort the current conflict resolution process, and try to reconstruct the pre-merge state.
If there were uncommitted worktree changes present when the merge started, git merge --abort
will in some cases be unable to reconstruct these changes. It is therefore recommended
to always commit or stash your changes before running git merge.
git merge --abort is equivalent to git reset --merge when MERGE_HEAD is present.
It has a default setting. You can set the default in your .hg file. When you pull your repo from somewhere that becomes the default. You can also specify where you want to push to.
But I'm not really sure that pushing is that much of a difficult concept, because you just have to add a remote and then use this to do your push. Not really that much of a difference...
Edit: I've just realized... I probably need to clarify the command:
The only git keywords here are "remote add". Origin could be named anything you want (call it "external"), and the git@example.com:my_project.git is actually what points to the git remote repository. You can also use the same style URI if you want to use SSH, or even HTTP(S).
I understand, your argument is why I used Dropbox's primitive version control over SVN. I never had to think about it.
But now I use git, and I don't even consider myself an engineer. I do front-end. Structurally speaking, git makes 10x more sense to me than SVN ever did.
git is not just some other utility. The comparison to screen savers is not adequate. git is an advanced system tool meant for software engineers. That's why I compare it to a programming language or an operating system.
Also, the return on investment is huge.
I think that time spent learning git is time well spent.
I would argue that you aren't learning a computer utility, but rather learning how distributed version control works. I honestly can't find anything in the author's post that doesn't make sense for DVCS.
> I don't know if anyone shares my experience, but I actually found svn rather mysterious and difficult to understand. I never actually saw the point to it at all, so I never bothered using it (unless it was mandated by some authority).
There is no point to Subversion or Perforce, unless it's mandated by some authority. The purpose is for that authority, not for you the programmer. That's the essential difference--in P4 or SVN, the authority has version control and you the programmer do not. In Git, everyone has version control.
Another concept users need to understand is the index. That causes confusion if you don't understand the idea that there's a cache in between what's checked in and what's on your disk.
I consider git to be almost like a programming language.
The information model is not complex, it's actually quite simple if you really understand it.
* blob: roughly a file (without a name)
* tree: roughly a dir (maps names to blobs and trees)
* commit: tree + parent commit(s) + meta data (author, commit msg, etc).
If you grok this core data model, a lot of things will make much more sense.
http://git-scm.com/book/en/Git-Internals-Git-Objects
I don't know if anyone shares my experience, but I actually found svn rather mysterious and difficult to understand. I never actually saw the point to it at all, so I never bothered using it (unless it was mandated by some authority).
It's only when I understood git that I really understood what version control is supposed to be about.
So, I think people who try to "dumb it down" by giving tutorials that ignore the data model and focus only on the usage are not doing anyone a favor.
Git should be treated like a new programming language or a new operating system. Spend a few days reading (or watching youtube videos) about how it works and why it was designed this way.
Yes, you really have to understand how it works. But it's precisely the fact that you can do so, that make git the best version control system out there in my opinion.