I would much rather rely on my backups than a knowledge of theoretical computer science to prevent me from losing things.
I have to use git/svn/mercurial from time to time, saying the internals of each vcs is essential knowledge is making quite a lot of assumptions about my time and how these tools are used.
people use thousands of tools every day, you can make the same argument "you know know the internals so you can use them properly" for each one, which sounds like a pretty surefire way of never getting anything done.
I didn't say it's essential for other source control systems. It's only essential for git.
This is why git is so annoying to learn and I'm reluctant to recommend it. Unlike, say, a filesystem where you can understand it at the POSIX level and there's no reason to understand disk sectors, the internals of git are exposed and there's no simpler model of how it works. Many of the commands don't make sense unless you start to understand the internals.
I think the fact that git forces you to learn how it works is one of its greatest strengths.
It's not like it's rocket science either; git's internals are remarkably straightforward considering what it can do. By having a rudimentary understanding of what git actually is, even supposedly "advanced" features like rebasing and partial commits (git add --patch) make perfect sense.
Git is a tool that will be used constantly. It pays to learn it thoroughly.
The UI of the command line tool is sometimes iffy (git rm --cached?), but that I think is a separate issue. The other VCS systems, being so "user-friendly", don't seem to encourage one to actually learn them. Mercurial's branches still don't make sense to me (bookmarks are better), and SVN I can use almost solely because I've learned some magic incantations that work for what I need to do.
Comments
I would much rather rely on my backups than a knowledge of theoretical computer science to prevent me from losing things.
I have to use git/svn/mercurial from time to time, saying the internals of each vcs is essential knowledge is making quite a lot of assumptions about my time and how these tools are used.
people use thousands of tools every day, you can make the same argument "you know know the internals so you can use them properly" for each one, which sounds like a pretty surefire way of never getting anything done.
I didn't say it's essential for other source control systems. It's only essential for git.
This is why git is so annoying to learn and I'm reluctant to recommend it. Unlike, say, a filesystem where you can understand it at the POSIX level and there's no reason to understand disk sectors, the internals of git are exposed and there's no simpler model of how it works. Many of the commands don't make sense unless you start to understand the internals.
I think the fact that git forces you to learn how it works is one of its greatest strengths.
It's not like it's rocket science either; git's internals are remarkably straightforward considering what it can do. By having a rudimentary understanding of what git actually is, even supposedly "advanced" features like rebasing and partial commits (git add --patch) make perfect sense.
Git is a tool that will be used constantly. It pays to learn it thoroughly.
The UI of the command line tool is sometimes iffy (git rm --cached?), but that I think is a separate issue. The other VCS systems, being so "user-friendly", don't seem to encourage one to actually learn them. Mercurial's branches still don't make sense to me (bookmarks are better), and SVN I can use almost solely because I've learned some magic incantations that work for what I need to do.