"You go to commit some code to a public repo. The maintainer scolds you for using merges instead of fast forwards."
"You decide to bring in some more code from the public repo. Here is a 6000 word essay on what rebase means."
"You try to look at an old version of the code. Suddenly you are in ‘detached HEAD’ state. The End."
I love git, but simple intros like this hide all the confusing complexity and awkward UI that quickly comes to the forefront when using git for everyday work.
I teach courses on Git, and I couldn't agree more. Many of my students have been told that Git is simple, and they just need to know 10 commands. Or they can think about it like SVN. Or that they should push, pull, and that's about it.
Which has the effect of (a) making them fear Git, (b) making them feel like they'll never figure it out, (c) and convincing them that they're always on the verge of losing data. I've literally had students at the start of my course refer to Git as "that system that makes me lose files."
Once I teach people about Git's objects and data structures, things suddenly become much more obvious to these people. Git becomes less of a mystery.
I'm not saying that Git is easy for people to understand or use, because it isn't. It has a steep learning curve -- one which I think is worth the effort. But I think that it does a disservice to Git newbies to try to summarize all of Git's functionality in a short essay, and then proclaim, "See? There's not that much to learn here!"
Agreed: attempting to teach that git is simple does people a great disservice.
To be very effective and safe using git, you really do need to understand a bit about its inner workings. I find that to be a big weakness of the tool, and it continues to surprise me that it's become as popular as it has. I personally like git a lot, and find it to be very powerful, but it took time and an interest in deep learning to get there.
I can certainly understand that most people might want a simple VCS that's easy to use and makes it difficult to screw up. Git is not that VCS, by any means.
I would be grateful for your course. I've used git now for 3+ years and still don't feel like I understand Git's objects and data structures. Maybe it's because I didn't finish my PhD.
Finishing a PhD gives you bragging rights, but it doesn't make you any smarter! (Believe me, it took me 11 years to do mine... and I've got the bills and emotional scars to prove it!)
I might start to teach courses online at some point, but I'm right now so busy with in-person classes in Israel and China (with a bit in Europe probably happening soon) that I haven't had a chance to consider it. But hmm, maybe...
Meanwhile, see my above reply with some suggested resources to learn about and understand Git. I hope that they'll help.
Do a google video search for a presentation called "Git Happens" (by Jessica Kerr). The presenter does a really good job of digging into the data structures.
I personally think git is simple. That doesn't mean it's easy. The issues listed in the GP comment seem to me mostly social. I think the most common problems with git stem from a more general difficulty in working with a branching, asynchronously developed codebase.
About merges... I think rebase is ridiculously overused, and people should use merges more. Clearly a feature branch littered with spurious merges is bad, but often it seems that this is taken simply to mean that merges are bad, and I get the impression that people go to ridiculous lengths with rebase etc. just to preserve an illusion of linear history even in cases where merging would be better.
I have a whole "Git" category on my http://DailyTechVideo.com/ site, which are some of my favorite intros to Git.
Of these, my particular favorite is Michael Schwern’s “Git for ages 4 and up." Watch this, and suddenly Git will make a ton of sense. Jessica Kerr's talk about Git is a close second; it's remarkable for telling us about how Git thinks about things without showing any code.
One of my favorite tools to use in my Git course is this site:
which graphically shows what happens when you commit vs. change branches vs. rebase. Super cool stuff.
If you go through the two of these, and if you understand them, I think that you'll have about 90% of what you need to then re-read a Git introduction, and have things make sense.
I have to laugh a little at this. You just said, "Go through these 2 tutorials, and try out this tool, and then you'll be able to re-read the introduction and understand it (90%)!" I've learned Source Safe, Perforce, and svn in a matter of hours without having to re-read anything. It's absurd to have to watch 2 tutorials and read an additional book twice to understand something that you should basically already understand. Someone really needs to fix this!
I'm not saying that it's necessarily good that using Git basically requires understanding its data structures. But Git is hard to learn, and often hard to use, and surprises people who use it.
The best solution to this problem, I've found, is for people to learn how Git works. Once that happens, everything else falls into place, and their lives are much easier.
So is it ridiculous that you can only understand the Git documentation and tutorials after you understand the data structures? Yes. But Git isn't going away, and if we want people to succeed with it, then we need to help them to learn it, rather than castigate them for using a tool that they need to use for their work.
given that you teach it in-person, I feel that if you were to take the time to write an essay you would automatically bring up the hurdles and a lot of people would find it useful. why not go ahead! You can summarize/start here if you want, we'll give you feedback :)
You're totally right. I'll add this to the list of posts that I really want to write on my blog. I've got a crazy week coming up, but I hope to be able to push out a few posts after that. (Plane trips to/from China are very useful for catching up on reading, writing, and movies...) Thanks for the encouragement!
> "You go to commit some code to a public repo. The maintainer scolds you for using merges instead of fast forwards."
Imagine you clone a repo. So your version is identical. You now add a couple more commits to master. Now, to make them identical again, all you have to do is upload the new commits, and then get his master branch to update to point to the latest one. Makes sense, right? That's a fast-forward.
Instead, what you do is merge your latest commit with the older commit two back, which creates a third commit with identical content to the previous one. That's silly, right? That's why fast-forward instead of merge.
> "You decide to bring in some more code from the public repo. Here is a 6000 word essay on what rebase means."
Rebase is when you take the content from a chain of commits, and make a completely new chain with that same content, just because it makes it look neater. You then change the branch from pointing at the head of the old chain to pointing at the head of the new. That's all it does. The old chain is still there until it's garbage collected a few weeks later (or you tag it to stop it disappearing).
> "You try to look at an old version of the code. Suddenly you are in ‘detached HEAD’ state. The End."
I'm not sure what the fear is here, so I'm not sure what to tell you. Create a test repository with a few commits and change the hashes below for real ones:
git checkout master # on master, whew
git checkout e34a53 # oh no, detached head
git checkout master # it's ok, back on master, whew
git checkout 343a34 # oh no, detached head
git checkout master # it's ok, back on master, whew
git checkout fe34ee # oh no, detached head
git checkout master # it's ok, back on master, whew
git checkout a567ed # oh no, detached head
git checkout master # it's ok, back on master, whew
I wrote a deploy script for our QA system that checks out the commit hash we want instead of the branch and leaves it in detached head mode. Works awesome. Needless to say our ops guys were not amused and demanded it leave it on a branch. People can be do stubbornly stupid sometimes.
I spent a few weeks working with Git, taking full advantage of the cool history-rewriting stuff it can do that Mercurial still doesn't quite match. It worked, but it required the most arcane syntax I've ever seen.
Then I gave up and went back to Mercurial. It does a much better job with subrepos, and I can actually use it without always consulting a hand-scrawled reference sheet for common tasks.
Took me many steps to finally internalize enough of git internals (still a tiny bit) to start losing fear and discomfort. I find it very similar to learning the semantic of dynamic languages (python: http://www.pythontutor.com/, js) where you need to see the data model evolving next to the main `pointers`. It looks obscure but it's not large. Small things aren't easy but not necessarily complex #hickeyism.
Is this an intro or a summary? Because I don't think there's any easy path to learning git, but there's a path, and it goes through understanding the internals, not memorizing UI idiosyncrasies.
The thing about git is that the internals are sensible and cohesive, whereas the UI is a train wreck. This is the opposite of svn where the UI is simple, but the internals are a train wreck.
The simpler subset is useful for personal or internal projects, however, so it's useful to have it spelled out.
(And BTW my own simple subset is still simpler - no branches, for instance, as it helps people delay merges which IMO they tend to overdo even without branches; also helps people pull and think they "got the changes" without actually running the new stuff. Also, my own understanding of rebases, detached heads etc. etc. is minimal at best and I seriously dislike having to learn that sort of thing and having to keep it in mind.)
"You decide to bring in some more code from the public repo. Here is a 6000 word essay on what rebase means."
"You try to look at an old version of the code. Suddenly you are in ‘detached HEAD’ state. The End."
I love git, but simple intros like this hide all the confusing complexity and awkward UI that quickly comes to the forefront when using git for everyday work.