How many kids want to go to school and how many are told by their parents that 'this is what you do so you can be happy and successful later.' I suspect more of the latter.
But like leaning Git, earning your education will pay off. Does that mean Git is without flaws? Of course not. And if you want to work to improve it, and release a better version, go for it. But anybody that sticks with SVN and refuses to learn modern DVCS is not somebody I'd hire.
Maybe this is a problem on IT-department, line-of-business teams (where most software developers work) but if Bay Area tech companies are a leading indicator, a big majority of Engineers I work with use and love DVCS's like Git and HG and there's not this groundswell of resistance.
And while this isn't related to my previous comments:
To anybody who has tried Git and ended up "losing work" because of a misunderstanding of the commands, let me assure you: It's actually a lot harder to lose work than you think.
Anything you add to the Index (eg git add foo.py) or commit is stored in the Reflog (which is just a DAG). The reflog is garbage collected periodically -- see below for details. Within that window, you can recover any lost state from the reflog.
So how long does Git keep things around by default?
Intermediate products of conflicted merges - 15 Days
Unreachable commits (do a git reset --hard HEAD~1?) - 30 Days
Intermediate products of a resolved merge conflict? - 60 Days
> But anybody that sticks with SVN and refuses to learn modern DVCS is not somebody I'd hire.
You wouldn't hire me. I'm OK with that.
I use git (required for an assortment of OSS projects), but for my own work, at at work, I use SVN. I'd never willingly choose git.
It's complex, involved, powerful, and incredibly distracting from the actual thing I want to do, which is write software.
The minute someone says something like this, my eyes glaze over: "Anything you add to the Index (eg git add foo.py) or commit is stored in the Reflog (which is just a DAG)."
Not because I don't understand git's fundamental model, or I'm unfamiliar with a DAG, but simply because I SHOULD NOT HAVE TO CARE.
My job is to write software, not operate heavy revision control machinery to some arbitrary level of dvcs revision control fetish perfectionism.
I don't want to hide my work from my coworkers, I don't wind to hide my work history from my coworkers, and I don't want to maintain wildly diverging branches (the cost of branches is primarily found in code divergence, not SCM headaches). Git isn't for me.
You sound like you've got a "production line" mindset. "This is my narrowly defined job, I'm not interested in learning new things, I just wanna do what I'm paid to do and get out."
That's fine and all, but I want to work with craftsmen. People who give a shit about their trade, love their tools and relish in the oportunity to learn something that will help them do their job better. I wouldn't hire you.
Git has a terrible, terrible, command line UI. It's entirely possible to do distributed source control with an easy command line interface: Mercurial. I've never had trouble teaching people how to use it, and I've almost never had to sit around scratching my head, wondering what arbitrary set of command line arguments I need to pass to it.
Maybe git is the most powerful chainsaw ever devised, but the fact that so many of its users are either covered in bandages or fastidiously studying man pages and googling proper usage so they don't end up covered in bandages is not a good sign.
I really like Mercurial, but even with it I've had some trouble getting the other developers I work with to really understand it. I could not imagine trying to show them Git. I think those who have mastered Git are blinding by how Smart and wizard-like they feel.
I also think its worth pointing out that many of the people here complaining about Git (including the OP), use it very frequently. These are the people who have bothered to invest the time in learning the tool and hate it anyway.
I'm fine with learning new things. I do use git on a number of projects: I just don't think it helps me do my job better.
The job of a SCM, in my opinion, is to be as invisible as possible. Record my commits, and then stay out of the way of what I'm really here to do: write code, architect systems, engineer products.
Futzing around with an overly complex revision control system doesn't help me do a better job.
This is also why I switched from Linux & BSD desktops to Max OS X. I can still write an XFree86 config file by hand, and the fact that I spent time and effort learning this is mind bogglingly awful.
I almost had an heart attack after doing `git push --mirror`.
It deleted 95% of branches locally and on origin without leaving much of a trace, or any way to undo (well, none that i know of).
Good thing I had a clone on a machine at home, so I drove home, made local branches for each remote branch and then pushed each.
So yeah, there might be a way to get that stuff back, and I don't even have experience with non-DVCS, but the lesson I learned a long time ago with darcs is that you better have up-to-date off-site backups of your repositories, never trust yourself or your DVCS too much.
The upside is that keeping backups is easy, and good practice anyway, so if you're not doing it yet, don't wait.
My worst experience on that front was with jekyll.
Running jekyll without parameters compiles the source in the current directory, putting the output either in $PWD/_site, or wherever the config file for the project says.
I was in the parent directory, and thought I'd try to run
jekyll projectname
rather than having to cd in and out of the project.
The end result? It tries to compile the project in the current directory, writing output to the directory specified. As an added bonus, it completely nukes the target directory, including the .git subdir. And to add insult to injury, $PWD didn't even contain a valid project, so it error'd out immediately after wiping out the entire source.
The morale of the story: Always keep offsite backups.
But like leaning Git, earning your education will pay off. Does that mean Git is without flaws? Of course not. And if you want to work to improve it, and release a better version, go for it. But anybody that sticks with SVN and refuses to learn modern DVCS is not somebody I'd hire.
Maybe this is a problem on IT-department, line-of-business teams (where most software developers work) but if Bay Area tech companies are a leading indicator, a big majority of Engineers I work with use and love DVCS's like Git and HG and there's not this groundswell of resistance.
And while this isn't related to my previous comments:
To anybody who has tried Git and ended up "losing work" because of a misunderstanding of the commands, let me assure you: It's actually a lot harder to lose work than you think.
Anything you add to the Index (eg git add foo.py) or commit is stored in the Reflog (which is just a DAG). The reflog is garbage collected periodically -- see below for details. Within that window, you can recover any lost state from the reflog.
So how long does Git keep things around by default?
Intermediate products of conflicted merges - 15 Days
Unreachable commits (do a git reset --hard HEAD~1?) - 30 Days
Intermediate products of a resolved merge conflict? - 60 Days
Everything Else? - At least 90 days.