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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
