Git's rise to become the de facto standard revision control system has been fascinating to watch.
I think it does provided real benefit over Subversion, but there are also smaller projects where the gain is marginal.
The tooling around (in particular GitHub) and perception that git is the "right" way to do things probably helped it achieve prominence. As well as early adoption by a few high profile projects.
It's well designed in the open source philosophy. It's designed for people who are spread all over the world, working together but in seperate, isolated repositories. There probably well are quite a few use cases where Git is not the best suited tool for the task. I don't doubt there are several situations where a team's workflow can be improved and sped up by everyone using SVN, especially if everyone works together and in the same building for the most part.
That being said, most complaints about Git are of its difficulty for newcomers, non straightforward workflow, and lack of clear, concise documentation. Once the concept is reasonably grok'ed, one would likely be hard pressed to find a developer who prefers a centralized system such as SVN over Git.
Is it that hard to understand that `git add` adds files to the list of files tracked by the repository (which is updated when changes are committed to it) and `git checkout` checks out a version that has been previously committed?
I mean, that's pretty much how all version control systems operate. Is it that hard to wrap anyone's head around the basic functionality that is common to any version control system in use?
No, it's not that hard to understand. It's also not how Git actually works. You're ignoring, or perhaps forgetting, the concepts of the index ("staging area"), and the many and various things which both these commands actually do, and the fashions in which these sorts of "oh, it's simple, really!" elisions betray those not yet experienced enough to recognize them for the overextended abstractions they are.
I'm talking about the same Git as the article author is. If you have a different Git in mind, please point me to it! Perhaps I would prefer to use that one instead.
He? Branching in GIT is natural thing to do where in SVN it is at least not user friendly.
"Subversion has no internal concept of a branch—it knows only how to make copies"
Now even if I do not need distributed features of git, I have VCS with local repo with git and I have easy branching.
So even if I work on my side project I use branching a lot because I can do cheap experiment branches, go back to previous state or pick what I liked in my experiment. For me it is just totally different approach to development. When I stopped using Subversion and started using GIT my world changed for better, GIT gives me more control. I can pick parts of files to be staged or pick what I need to be commited. Where partial commits with subversion is at least black magic.
So even for smaller projects it is like a whole world of difference for using GIT.
I don't understand the hostility towards it. These types of complaints like "oh if you misuse this tool that you didn't bother learning about, it does things you probably didn't expect" are basically completely useless.
Try randomly slapping your hands on a keyboard and writing software in <insert language>. Now complain that because you can't do that, <insert language> sucks. That's basically how I see these types of complaints about git.
Either I don't get most of the koans or they are intended to disparage git's UX instead of truly enlighten. Is the joke just going over my head or am I not thinking hard enough?
A Koan is "a paradoxical anecdote or riddle, used in Zen Buddhism to demonstrate the inadequacy of logical reasoning and to provoke enlightenment"
I think that kinda implicitly means the author considers git to be either paradoxical or illogical. That seems even more clear from the last two paragraphs of "The Hobgoblin".
That's a reference to an Emerson quote; if I remember rightly it's "A foolish consistency is the hobgoblin of little minds". I suspect the implication is that only little minds expect consistency... but over and above Emerson being a questionable source for UI design principles, he qualifies it. The quote isn't "Consistency is the hobgoblin of little minds."
I didn't read the hobgoblin the same way as the author being purely critical. I read it as a defense: a similarity between commands would make it easier to choose the wrong one. Removing a branch is a more destructive than deleting a file, so it should be a command chosen with conscious care rather than muscle memory.
I can't speak for the author's intention, but yes, these "koans" highlight some of git's worst UX warts; or, arguably, not just UX warts but conflicts internal to the conceptual underpinnings of git (http://people.csail.mit.edu/sperezde/onward13.pdf).
> but yes, these "koans" highlight some of git's worst UX warts; or, arguably, not just UX warts but conflicts internal to the conceptual underpinnings of git
If that's the case, the "One Thing Well" kohan misses the mark rather glaringly.
I feel like they're meant to be jokey about UX failings, but I'm unsure what the author is trying to convey.
For example:
> [something about history being present and immutable]
>“Splendid!” exclaimed the historian. “I have a historical record of a merge commit with two parents. How can I find out which branch each parent was originally made on?”
>“History is ephemeral,” replied Master Git, “the knowledge you seek can be answered only by the gods.”
the pedantic explanation here is that branches are a separate subsystem, with each branch just being a pointer to a commit. And the history works off of the commit.
The answer from "Master Git" doesn't feel like an answer from a master. Maybe I'm reading too much into this but Git becomes way less confusing if you think more about what things are, rather than how they're used .
It's my favorite way to learn the syntax for a new language.
Also, should the checkout one be enlightening? I never thought about it, despite using git every day, but overloading git checkout like that seems like it should be confusing.
I think the point is that these things should not require enlightenment, but do. They ARE confusing. These are the kinds of examples that people have in mind when every git thread devolves to an argument over whether it's a good tool, power vs UX, because apparently that's a tradeoff you have to make.
Mercurial's UX is miles better, and to the best of my understanding, its guts are conceptually very similar. It's slow on larger repos and histories, but other than that, I don't see why it doesn't get more love.
Approaches like these seem packed with mnemonic benefits. As I read, I kept thinking about how I would try to assemble something like this about git, and the result is a really sort of intriguing learning experience.
"How can I find out which branch each parent was originally made on" -- ouch. Ive dreamed of automatically tacking on branch names to commit messages to solve this very issue.
We use Jira and bitbucket - most if not all branch names contain an issue number and the name of the issue, while commit messages can be more cryptic. This is often helpful when the branch has been deleted, as it usually is.
We use bitbucket server for pull requests and merges, and it does this. It's brilliant, since the branch name often describes the solved problem better than the commit messages.
To add a bit more context: I think that the author came to use git /after/ they learned mercurial. For a long time mercurial's history was completely immutable, and hg's branches are very different from git ones (the mercurial equivalent of git branches is called bookmarks).
I actually quite like this syntax for deleting remote branches. You can think of it as a special case of
git push $remote $local_commit:$remote_branch
which updates the remote ref $remote_branch so that it points to $local_commit; here it updates the remote ref so that it points to nothing (which means deleting it). Sure, this is inconsistent with other git commands, but it's not completely illogical. Though I'd probably prefer something like
git push $remote $remote_branch=$local_commit
where the '=' makes you think of assignment, hinting at what this command actually does.
there is ClojureScript Koans if you want to learn tiny bits of FP. I held a meetup event once everyone really liked it. Since we were all learning JavaScript already
To be honest, this is the first criticism of Git I've read that I can see making concrete, coherent, actionable points. And I actually agree with some of them.
Most other complaints about git I've seen seem to be of the vague 'but git is sooooo confusing' sort, which just invites people to talk past each other.
Git's rise to become the de facto standard revision control system has been fascinating to watch.
I think it does provided real benefit over Subversion, but there are also smaller projects where the gain is marginal.
The tooling around (in particular GitHub) and perception that git is the "right" way to do things probably helped it achieve prominence. As well as early adoption by a few high profile projects.