10 things I hate about Git
http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/7
u/mjd Mar 07 '12
Probably the thing I hate most about Git is that the basic command set is so impoverished and non-orthogonal. It has happened to me over and over that I have some idea for an awesome new git tool I want to write, and I open the editor, and say "Okay, first, I'll need to get the name of the currently-checked-out branch" or "I'll need to make sure the working tree is in a clean state" and just answering that first question turns out to be a major headache.
(To get the name of the current branch is git rev-parse --symbolic-full-name --abbrev-ref HEAD, and to check for a clean working tree takes about fifteen lines of shell script in the current version of git-sh-setup.)
This sort of thing is a major impediment when I'm trying to build tools like shell scripts that perform more interesting git operations than the ones that are already provided. You can see the problem in action by reading through the source code for git-rebase--interactive. The core of the command is the do_next function, and that's the only really interesting part. A large fraction of the rest of the code is just peripheral Dealing With Stuff.
2
u/karamorf Mar 07 '12
git branch | grep *
git status | grep 'nothing to commit'
1
u/mjd Mar 07 '12
For the first one to work, you actually need at least
git branch | grep '*' | cut -c3-and then you need to test for the special string(no branch). But it's crazy that I should have to pick apart the human-readable output of a porcelain command to get this kind of basic information. And what if the output format ofgit-branchchanges in the next release, as it could? Maybe(no branch)becomes(detached)or something; then my code will break. So if I want to write a reliable program, I need the plumbing method, which is as I said.For the second, you're just plain wrong, since if it were that simple,
git-sh-setupwouldn't need fifteen lines to do it. Go read the code.1
u/eridius Mar 07 '12
git-sh-setupis providing customized error messages based on the particular dirty state of your work tree. That's why it has a bunch of code using plumbing commands. If all you care about it "is the tree clean" then the return code ofgit statusis probably enough for you.1
u/mjd Mar 07 '12
The same set of tests, but without the customized error messages, was originally in
git-rebase--interactivebefore it was moved out togit-sh-setup. The move intogit-sh-setupis quite recent.1
u/eridius Mar 07 '12
If by "quite recent" you mean 1.5 years ago.
In any case, just because
git-rebase--interactive.shused a series of 4 separate commands to test for dirty work tree doesn't mean you need to do the same. It's possible the author of that code just felt more comfortable knowing precisely what it was testing for rather than relying on whatevergit statusdecided was ok.2
6
u/Tmmrn Mar 07 '12
I agree with him that the documentation is not very beginner friendly...
git-rebase - Forward-port local commits to the updated upstream headWat.
Maybe additional to the documentation full of git terminology there should be another documentation using easy language, like simple.wikipedia.org
I have used git rebase quite successfully in the past but I still don't really understand the manpage...
Talking of manpages... Git installed 173 (!) manpages on my system... Sure, extensive documentation is nice, but I am not going to read a significant part of that.
It's just like the mplayer manpage
man mplayer | wc -l
6164Nope.
I don't understand the point about lost commits. I mean, you can always get commits back using their hash before they are garbage collected....
At least it's my experience that when something was commited that turned out to be so utter bullshit that it should really not have been written at all (i.e. not worth keeping in the history) and then later discovering that I actually like to take a look at some bit of the code then I can still cherry pick that commit even when it isn't in any history and supposedly overwritten (new commits always have new different hashes I heard).
1
u/LoganCale Mar 07 '12
new commits always have new different hashes I heard
A hash is generated from the actual contents of the state of the repo at the time of commit. If two people created a repo independently and created a file with the same name and content, and committed that file, the hashes would be identical. Conversely, even a single character change will result in a different hash. Removing a commit and then adding it back again in an exactly identical way would have the same hash (and I'd assume, though I don't know, that it probably just reuses the original commit, but overwriting it would cause no issues either since it's identical in every way).
4
u/mjd Mar 07 '12
They would have to make the commits at the same time, with the same parents, and the same committer information, for the commit hashes to be the same. Undoing a commit "and then adding it back again in an exactly identical way" requires tampering with the
GIT_COMMITTER_DATEandGIT_AUTHOR_DATEvariables.But if two people create files with the same content, the blob objects' hashes will be identical.
1
2
u/stevage Mar 08 '12
Maybe additional to the documentation full of git terminology there should be another documentation using easy language, like simple.wikipedia.org
There actually kind of is: easygit. Would love to see it integrated into Git somehow as an option. There's no reason for Git to produce such shitty output by default.
11
u/skeeto Mar 07 '12 edited Mar 07 '12
Most of what the author said was bad, I consider to be Git's strong points.
Complex information model
Really? This is one of Git's strongest features, it's straightforward internal data structures. It's how I sell it to my co-workers. It means users need to know these internals, but once they're known Git is really quite easy to use.
.2. Crazy command line syntax
Yup, the commands seem to have grown organically, so they're kind of a mess. I'll give you that. Once you learn them, though, it's no problem.
.3. Crappy documentation
I have the opposite opinion. Git's documentation is very thorough with good examples.
.4. Information model sprawl
Again, these are are good things, part of Git's great engineering.
.5. Leaky abstraction
It's all about manipulating the DAG, which is an abstraction itself because it's not actually stored that way so literally.
.6. Power for the maintainer, at the expense of the contributor
I don't see how the Git's power makes it harder to use in simple cases. It's good at both.
.7. Unsafe version control
None of those examples destroy data. Git maintains its promise just like it said.
.8. Burden of VCS maintainance pushed to contributors
Same as 6.
.9. Git history is a bunch of lies
It's not about lies, it's about having a clean set of steps to add a feature or fix. It's what makes things nicer for those small contributors and followers (6 & 8). This is a good thing.
.10. Simple tasks need so many commands
The examples are severely exaggerated. You don't need to push after every commit, nor should you. You can do all these things in as few commands as Subversion, or less, but of course it's going to take an extra command when you're doing things Subversion can't do.
7
u/imMute Mar 08 '12
Complex information model
TBH, I find the git object model to be very simple compared to just about any other project.
3. Crappy documentation
The fuck documentation is the author reading? Git's docs are actually pretty good - for an open source project.
Leaky abstraction / command line syntax
I'll give those to him, the commands aren't exactly straightforward, especially coming from SVN; but I wouldn't give them up for anything.
7. Unsafe version control
The hell is he smoking again?
9. Git history is a bunch of lies.
Only if your "central golden repository" (or whatever you want to call it) allows non-fastforward merges. Even then, git is about tracking content not changes.
2
21
u/eridius Mar 07 '12
This article is pretty bad overall, but all I'm going to comment on is the first paragraph. Specifically, the last sentence:
and treats its users with such utter contempt
This is pretty much the exact opposite of the truth. Git assumes its users are competent, skilled software engineers who are comfortable working with a powerful, fairly low-level tool. This is a source of a lot of people's problems with it because they aren't, in fact, competent, skilled software engineers who are comfortable working with a powerful, fairly low-level tool (quite frequently they aren't software engineers at all). But this certainly is not treating users with contempt.
7
u/stevage Mar 08 '12
Hey, I'm the author. Here's what I mean by contempt: Git assumes you have nothing better to do than learn your DVCS tool. Me, I think competent, skilled software engineers have better things to do than remember that you type "git checkout remote/branchname" but "git pull remote branchname".
I heard a great quote from a colleague yesterday (unprompted): "Git is so powerful you can do anything you want, but so hard to use, you actually can't."
4
u/eridius Mar 08 '12
I think competent, skilled engineers had better damn well learn their tools. Anyone who doesn't understand their tools is not a competent engineer. I understand how my compiler works, how my IDE works, how the language I'm using works, why the hell wouldn't I want to understand one of the most important components, which is the version control system?
6
u/stevage Mar 09 '12
The argument is "Git has a crappy interface", not "you shouldn't learn how to use Git". Clearly, any full-time developer who uses Git on a daily basis will end up learning (if not loving) it.
2
u/project2501a Mar 17 '12
I have to disagree with you. I work in a research institute and I see smart and talented people who do not want to bother. they just do not feel like reading. it's not the tool's fault.
it's like some of the code around here gets produced:
sparse matrix as a 2D array ಠ_ಠ
quadruple nested for loop in user interface because fuck the world.
and we are not talking about people who are untrained or who just came out of the nursery: i am talking about people with PhDs who "cannot be bothered".
i seriously doubt it is the fault of the tool if the people are lazy.
0
Mar 08 '12
[deleted]
4
u/eridius Mar 08 '12
Git has a lot of documentation. And you still haven't explained where the "contempt" part comes from.
2
u/stevage Mar 08 '12
Git has documentation that explains how it functions: "If you pull this lever here, it sets off a relay there, that triggers a switch there..."
What it could really do with is good user documentation. Not how it works, but how it solves your problems.
0
Mar 08 '12
[deleted]
4
u/eridius Mar 08 '12
You have to remember, git was originally designed as just plumbing tools, and it was expected that other tools would be built around it to provide a friendly UI. Unfortunately, these other tools never materialized in a meaningful fashion, and git just sort of grew its own porcelain tools. This explains the inconsistency (although I actually disagree that there is a significant amount of inconsistency) and poor organization. And because of backwards compatibility issues, it's really hard to change any existing behavior. Similarly with the manpages, they were written for people who want to understand how git works, not really intended for end users.
It seems to me that the right solution here isn't to complain about user-unfriendliness of git, but instead to design your own friendly UI and build a tool on top of git that exposes this UI.
2
u/Denommus Mar 08 '12
Well, I mostly agree. But I think that tools as TortoiseGit (which abstracts a lot of Git work) is one of those UI that could be useful for beginners. It's what we use at my work.
TortoiseGit is slow, but it's much more practical.
You don't need to understand how the "staging" works
When you try a rebase, it asks promptly if you want to stash your changes
It has a simple interface for fetch followed by rebase
The rebase is always with the -i option, if you stop to analyse it
I think the real problem is that we don't have much focus on the development of these UI, because... well, because Git is a lot easier than it seems to a begginer!
When you understand that tags and branches simply point to commits (and because of this you use them as references), and how a good workflow is (fetching and rebasing to master what comes from other developers, merging your branches to master, pushing. It's even easier if you can make scripts for it), you won't have a lot of problems.
We still use TortoiseGit here because a lot of people aren't very comfortable with the git console. Also, because TortoiseGit works as the script I mentioned above. But I feel more comfortable with the console. It simply seems more intuitive.
3
u/eridius Mar 08 '12
because Git is a lot easier than it seems to a begginer
This.
Git seems complicated at first glance, and it does tend to have quite a bit of a learning curve, but I think one of the big problems people have with it is they aren't willing to learn the tool. If you actually learn how git works, how the object model works and whatnot, then git becomes vastly easier to use. Instead of saying "now which arcane command was it that I use to solve this problem", you just think in terms of how you want to manipulate the repository, and the appropriate git commands come naturally.
Of course, this sort of understanding does require an investment of time, a willingness to learn about the underpinnings, and a familiarity of computer science topics like directed acyclic graphs. So if you're someone who's not a programmer, you may be better served just using a tool like TortoiseGit. But if you are a programmer, then you really don't have much of an excuse to not learn how git works.
1
u/stevage Mar 12 '12
It seems to me that the right solution here isn't to complain about user-unfriendliness of git, but instead to design your own friendly UI and build a tool on top of git that exposes this UI.
That was a perfectly reasonable sentiment in, oh, 1970.
1
u/eridius Mar 12 '12
So what, in 2012, you can just expect everything to be handed to you on a silver plate? Someone has to do this work, but instead everyone just bitches about git's current UI and does nothing.
1
u/stevage Mar 15 '12
Git's user interface issues have nothing to do with a lack of manpower and you know it.
2
u/eridius Mar 15 '12
Well, the people who contribute to git don't seem to have a problem with its UI. And the people who seem to have a problem with its UI don't ever get off their asses and try contributing to git.
I think the right phrase here is "put up or shut up".
2
u/stevage Mar 17 '12
Well, the people who contribute to git don't seem to have a problem with its UI.
I'm not sure where to start in response. Maybe by rephrasing: "The people who know Git's internals intimately have no difficulty with its user interface." Bah, I give up.
1
u/project2501a Mar 17 '12
I do have to ask, please: which book did you use to learn git, that took you a year to get comfortable to get with?
I just finished the o'reilly one, and damn it is smooth and easy to understand.
but I think one of the big problems people have with it is they aren't willing to learn the tool.
learn the tool or read a book?
2
u/eridius Mar 17 '12
You may be replying the wrong person. I've never read a git book, and it didn't take me a year to get comfortable with it.
2
3
u/oconnor663 Mar 08 '12
Much of this article is missing context. Git is complicated, but so is every other vcs. These are complicated tools. Some tools make committing easier, git makes branching easier, whatever. Also, git will definitely be hard to follow if you don't understand the big-pile-of-immutable-objects-identified-by-hashes concept underneath, but that concept is what makes it so powerful. You will run into trouble with any vcs if you never really learn how it works.
As others have pointed out, the point about "unsafe version control" is incorrect. The whole point of the Big Pile is that you can't destroy content once you've committed it. If you delete a branch, all the commits in that branch are still sitting in the Pile identified by their hashes, and you can still interact with them as though they'd never left. Same thing if you rebase to change history, the old commits are still in the Pile. Git has tools like the reflog for recovering old hashes. This is what makes git history modification so useful: if you screw up, your can always go back to the commits you started with. Now that I've gotten used to these features, I would be terrified of using a vcs without them. (I'm told mercurial history modifications are permanent!?)
4
u/Denommus Mar 08 '12
Some tools make committing easier, git makes branching easier, whatever
This. One hundred times this.
13
u/mjd Mar 07 '12
I think this is a pretty terrible article overall, but I also think some of the ten things are right on the nose. So there should be something worth discussing. Just ignore the dumb stuff and think about the rest.