You seem to think that other version control systems don't have this problem.
Let's consider subversion. Let's say you want to revert commit 1234. You just say "svn revert 1234", right? No. svn revert does something completely unrelated.
In git, "git revert 1234" does revert changeset 1234.
So you see, you actually have to learn about the version control system, regardless of which you choose.
You can't just make stuff up and expect the computer to understand what you mean.
Agreed! But I already know SVN, and Linus intentionally made git different than the other SCMs because he thinks they suck.
I think that's annoying.
And there's no way you can tell me that the git command set is more discoverable than, say, Mercruial's. Many common, every day commands in git are very difficult to figure out without a lot of searching and reading. This is not true with Mercurial.
Between `git help -a` to see all the available commands, and `git help <command>` or `man git-<command>`, I don't see how Git is any worse than any other VCS tool. Git is extremely well-documented, and even goes so far as to provide ASCII-diagrams in the docs to help you visualize what certain commands do.
Or are you just being picky because Git doesn't name everything exactly the same as other tools do?
I started with cvs, years ago, moved on to subversion when it was good and stable, and am now starting to fiddle with git. I like it a lot, but it is "fiddly" feeling. I'm sorry I can't describe it better than that, but it's just a feeling I get from it. Maybe this covers it: I don't get the feeling that it's going to much effort to "make the easy things simple and the hard things possible". We know it can do the latter, but the former is not always true.
"make the easy things simple and the hard things possible"
Well, it's Git, not Perl :)
I like it a lot, but it is "fiddly" feeling.
To assuage this feeling, I recommend reading the source code for both Git and Subversion. After you realize the flaky shoestring-and-chewing-gum model that holds all your data in subversion, you won't worry at all about Git's UI :)
i agree with this. i'm very happy with svn. my one foray into git was when i was working on somebody else's project on github, and i got a vague uneasy feeling about it. for one thing, the output it prints to the terminal seems needlessly complex and verbose.
What are your specific complaints, and are they anything more than the age-old "`git commit` doesn't commit everything by default"? I'm not trying to snark; I'm genuinely interested in what people find difficult about Git, that much more it's possible to "fix".
If there's something complex that you think should be easy, you always have two basic options:
- create an alias in your ~/.gitconfig linking a short command name to a long command/argument sequence
- create a shell script in /usr/libexec/git-core (or the equivalent) that does what you want, and you can instantly use that in the standard `git <command>` method.
For an example, I have aliased 'co' to 'checkout', 'ci' to 'commit -a', 'pullr' to 'pull --rebase', and 'fp' to 'format-patch --binary'.
Let's consider subversion. Let's say you want to revert commit 1234. You just say "svn revert 1234", right? No. svn revert does something completely unrelated.
In git, "git revert 1234" does revert changeset 1234.
So you see, you actually have to learn about the version control system, regardless of which you choose.
You can't just make stuff up and expect the computer to understand what you mean.