Re: Considering teaching plumbing to users harmful

On 7/16/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

I believe the only way you can get away with such a simple learning sequence is if your workflow is as simple as that you seem to describe: everyone has push access to the central 'master'.

That works (and mostly just as well as any other "supposedly easy" VCS, like svn), but because git's power is so tempting, almost nobody's real-life repository actually works like that.

At the very least, there will be branches. And where there are branches, there's merging. And with merging comes merge conflicts. And with merge conflicts comes the crazy (yes, very useful, but still crazy) conflicted index features. And so you suddenly need to find out about things like

       git diff :{1,3}:path/to/filename

Which is a great command, but svn definitely makes it easier to do the same thing.

Even if you have a repo with widespread push access, git's log looks annoying compared to svn because of all the merge commits. That's a primary reason why rebase was invented, of course. But teaching people about rebase vs. merge is highly nontrivial. "git pull --rebase" helps a little, but it's still nontrivial, particularly when local patch #3 of 5 has a conflict.

Also, inevitably, someone will ask "what happened to those simple svn revision numbers?" or "when I do a merge, why are the patches from branch #1 interspersed with the ones from branch #2 in git log?" The answers are "look at gitk to see the real merge history, that's way more powerful than svn, and check out git-bisect!" and "use git log --topo-order" respectively, but those are pretty nontrivial answers too.

Submodules, which are critical to large-scale software development, are also very complicated. You can't explain how to use them without knowing about .git/config, the difference between that and .gitmodules, the concept of gitlinks (and therefore the concepts of trees and blobs), the idea of a "disconnected HEAD" (which all submodules check out by default), the idea that pushing submodules in the wrong order can create references to non-existing commitids, and so on. In contrast, the lame svn:externals mechanism is far easier to explain.

The "problem" with learning git is that it's so powerful. A person can feel like they've "learned all the svn there is to learn" in a couple of days, because it really doesn't do all that much. But with git, if you want to make it *appear* simple, you have to artificially restrict what you tell people, and because the git *developers* don't work using that restricted subset of commands, the abstraction always leaks.

Example: "git remote" didn't originally even have an "rm" subcommand.
Why?  Because real git developers knew they could delete a remote by
editing .git/config, and it never even occurred to anyone to do it any
other way.  I still do it by editing the file, because the file is in
a nice format and it's still easier than typing "git remote".

The svn developers have the same annoyingly small subset of commands that their users do. It means svn is much less powerful, but it also means that subset is actually enough to somehow handle *all* the tasks a user will run into. After all, there's no other way.

That said, it's debatable if all this is actually a problem. If I wanted simple-minded, I'd use svn. Ironically, the plumbing is the only part of git that isn't supposed to ever change, so it's the most valuable knowledge to have. Why *not* teach it?

Have fun,

Avery