Superficially, I dislike it because it seems very little thought has been put into giving it a coherent interface. TFA points out instances of this, and it's true: whether something is implemented as its own command or as a flag to another command sometimes seems to have been decided via dartboard rather than any sort of intelligent process.The examples given weren't illogical. The author's examples were git pull, which he complains is a git fetch followed by a git merge... which is quite logical, given that to pull from a repository you must first fetch the files, and then merge the files into your repository.
The second example that he complains about git commit not commiting a file if it's not specified on the command line. This makes sense, as you need to explicitly add the files via git add - something the documentation makes clear. As one of the complaints is that the documentation isn't clear, I think it worthwhile mentioning that the git-commit man page specifically says:
The content to be added can be specified in several ways:
1. by using git add to incrementally "add" changes to the index before using
the commit command (Note: even modified files must be "added");
.
.
3. by listing files as arguments to the commit command, in which case the
commit will ignore changes staged in the index, and instead record the
current content of the listed files (which must already be known to git);
4. by using the -a switch with the commit command to automatically "add"
changes from all known files (i.e. all files that are already listed in
the index) and to automatically "rm" files in the index that have been
removed from the working tree, and then perform the actual commit;
The third example he used was that the shortcut for
git branch and
git checkout is
git checkout -b. However, this makes sense because a branch doesn't populate automatically with any files and needs a checkout. Thus
git checkout -b makes perfect sense.
Perhaps there needs to be a git branch -c?
I also do intensely dislike git's own man pages, which are the first thing I'd ordinarily turn to. Unfortunately, the concept of an acyclic graph has not yet arrived in that part of git.
I think some of the opening descriptions are a little terse, but not entirely sure what you mean by the acyclic graph comment... I haven't been able to find anything obvious in the man pages that references a man page that then references the original man page... of course, I might have missed something!
I dislike the way git overloads "branch" with multiple meanings or, rather, forces end users to do so.
Could you clarify what you mean? Branches have only one meaning in git!
I dislike the fact that every repository and every branch is on equal footing except for all the commands that work differently with a remote branch or require you to do extra setup before they do work.
Could you clarify what you mean?
I dislike the fact that side-by-side inspection of different branches requires me to jump through hoops, since git only wants me to see one branch at a time. SVN, for all its faults, at least got that one right -- I can actually see two different branches, at the same time, using tools that require no knowledge of anything beyond my filesystem.
Can't gitk do this? Genuinely interested...
I dislike the fact that even people who use git day in and day out still can't seem to agree on a workflow. And I'm not just talking about things like whether rebasing is fashionable this week, but very basic things like when and how to branch.
I really can't see that's a valid argument. Some folks need to branch differently than others. This isn't just a git thing, the same can occur in SVN. As has been pointed out, branching tends to be discouraged because merging can be a regular pain.
I also agree with the article's point about contributor workflow; git and GitHub are more complex for contributors. There's also very little that's "decentralized", since GitHub is full of canonical central repositories, which makes me wonder what we gain from pretending we're using the "D" in "DVCS".
I disagree. The github workflow might be a little tricky, but as has been pointed out there are other workflows possible in git. git != github!