> The OP already pointed out that the official Git documentation is bad, bad bad. So, already it's not just "RTFM" but "Google around for a decent Git tutorial and hope you pick the right one." Great.
I have a hard time believing that there are scores of software developers out there who have learned their craft enough to want source control but are somehow overwhelmed by the basic task of finding a good Git tutorial.
The real impediment that I've observed is developers that certainly could learn Git but don't because they don't see it as a good investment. That's where they're so, so wrong. Git is like power tools for your code. If you embrace and learn it, you'll be much better off for it. Yes, SVN is easier. It's also a lot less powerful.
And there's always Mercurial, which is very similar to Git and addresses some of the confusing-API criticism.
The problem with git isn't following a tutorial, the problems I have had are nasty corner cases. I have to keep looking up strange a-symmetries, like why does 'git push' push just the current branch, and 'git pull' pull all branches? Then I have to look up how to make 'git pull' pull just the current branch.
Also, due to inconsistencies in how commands take branches, I sometimes realise I have a branch called 'origin/stuff', when I meant to do something with stuff on origin. It's also hard to find which branches are tracking what. Of course, you can find the options to do all these things. But there are just so many little things to learnt.
The fundamental question is, does the complexity of git come from the power it offers over svn, or does it come from the most terrible UI I think I have ever seen on a command line tool? I think it is the second.
I still use git every day, but I think it is putting usability by less computer-savvy users back years.
> like why does 'git push' push just the current branch, and 'git pull' pull all branches?
It's the opposite, "git push" pushes all branches and "git pull" only pulls the current branch. I think it's because push will only do fast-forward merges while pull will do any merge, and that could require a working directory to exist (but why not make push just push the current branch?)
Sorry yes, I got the asymmetry the wrong way around :)
The problem this causes (for me) is that if I have commits in other branches, 'git push' will fail (as other branches can't be fast-forwarded), but 'git pull' won't fix it. Of course, I can get around it, but it's annoying.
What you mean when you say "you can get around it" is just specifying the branch you want to push. Just sayin'. It's not like you have to muck with settings and jump hoops.
The git maintainer is trying to fix this asymmetry by making "git push" only push the current branch (rather than all branches). It's a slow process to change the defaults in something as widely used as git because doing so breaks scripts.
> why does 'git push' push just the current branch, and 'git pull' pull all branches?
What version of git are you using? "git pull" definitely just pulls the current branch. It will fetch all the other remotes, but will only pull the current branch.
Which kind of makes sense, because you don't normally want to pull in all branches, just one particular be, but you often do want to push all your branches.
"...but are somehow overwhelmed by the basic task of finding a good Git tutorial."
Ummm.... when you don't know the tool, you're not in a good place to judge what a 'good' tutorial is. This is the same reason we've got generations of bad PHP developers out there - they can't tell what's good or not.
"scores of software developers out there who have learned their craft enough to want source control"
How many people 'want' to learn source control, and how many people are told 'this is what we use here, go learn it'? I suspect far more of the latter, especially with git. People would not flock to git purely based on the documentation quality. Further, I suspect that had git just been written by some random dude off the street with no major project behind it, it would have never taken off. Using it for Linux kernel work has ensured a sizeable number of people are going to have to use it, whether they like it or not.
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.
I started out with VCSes with bzr, which spoiled me very much, as everything's straightforward, it does whatever I want it to do, and it just works. I then moved to git, because it was much faster, but I couldn't handle it. Which command does the equivalent of "bzr revert -r -3"? What do I do to unstage things? What if I want to only revert some files? I don't even remember which of these things I know, because git threw random errors about things while running commands that were supposedly straightforward, or did things I didn't expect.
I tried hg for a time, which was much better, but in the end I went back to bzr (hg confused me in merging, with it thinking that "what is this three-way vimdiff window with all the colors? I'll just leave this and examine the files one by one" meant "okay, everything is correct now"). It interoperates with everything, and it's the sanest of the three, so why wouldn't I use something that just works, rather than fight my tools?
> Which command does the equivalent of "bzr revert -r -3"? What do I do to unstage things? What if I want to only revert some files?
git has well-documented and simple commands to perform these operations (except if you're talking about reverting some files in a commit, that's not a thing git does afaik? though it might, but I doubt it would be straightforward).
If you're confused by hg & git and just wound up back where you were it sounds like you just didn't have the patience to learn a new tool. Either that or you failed to evaluate what each tool did before you tried switching.
\sarc{bzr revert -r 3? What does that do? Jeez, bzr is so confusing.}
I don't think git's CLI design is that bad, but the commands for quotidian usage are hidden among a large and confusing array of commands for which serve to make git more powerful for the experts. This is also where the manuals are confusing: all the commands are listed, and beginners don't know where to start. It's like a woodwork hobbyist walking into the workshop of an expert carpenter and wondering where in the hell the hammers are.
As for subversion, try using it for branching and merging many parallel versions of code for very long and you'll welcome the arrival of git like that of Jesus into a leper colony.
I don't see that it's obtuse. If you learn the basic concepts (as you have to do when you are a beginner to subversion or CVS) then you shouldn't have much of an issue.
Now why would that be voted down? Obtuse means "mentally slow or emotionally insensitive", so that could hardly have been what was meant. I assume that by "obtuse" you meant "hard to understand". So I stand by my comment that if you learn the basics then it shouldn't be that hard to understand!
yb66 - you are hellbound. Not sure why the OS X dictionary would consider obtuse to be the same as abstruse (that's wrong!), but at least I now know what is really meant. Which is what I had assumed was actually meant (if you followed my original comment, then that's what I said!).
Tried to learn the basics to manage the code for my thesis. Gave up widely confused. After trying to revert changes, I went back to it, this time trying eGit and playing with the commands. Managed to get it to work, but still struggling with branches and merging of changes into master.
The whole time I was thinking if I'm stupid or talentless.
The discussion here showed me that git is indeed far from perfect.
I have a hard time believing that there are scores of software developers out there who have learned their craft enough to want source control but are somehow overwhelmed by the basic task of finding a good Git tutorial.
The real impediment that I've observed is developers that certainly could learn Git but don't because they don't see it as a good investment. That's where they're so, so wrong. Git is like power tools for your code. If you embrace and learn it, you'll be much better off for it. Yes, SVN is easier. It's also a lot less powerful.
And there's always Mercurial, which is very similar to Git and addresses some of the confusing-API criticism.