3 ms·

Mike, Git seems unintuitive because you don't have a good grasp of what it does behind the scenes. In other words, Git's abstraction is leaky. That's usually

Mike, Git seems unintuitive because you don't have a good grasp of what it does behind the scenes. In other words, Git's abstraction is leaky. That's usually considered a bad thing in our profession. Except that since it's Git, we all use it, and it's better than the alternatives, we all pretend that's a good thing in this case. I'm fine with the way Git works internally, and by now I've come to deal with the fact that sometimes it takes five commands to carry out what is, in fact, one desired action. But Git's main point of failure is typical of all young projects that are in any way involved with Linux - there's no effort to make it elegant or pretty, and anyone that points that out and suggests that maybe things could be easier is ridiculed for not understanding it. Usually "That's not very intuitive" is, in fact, an indication of something that could be improved...

tow21 16y ago
In other words, Git's abstraction is leaky No, it means you're using the wrong abstraction. As you change your codebase, files are modified. To the untrained eye, it looks like this a simple linear progression of history, and you just want to record savepoints as you go along. CVS lets you pretend this is the case. Actually, that's not the case at all. What you actually want to record is the changes you're making, and the relations between them. In the vanishingly small edge case where you never have any collaborators, never any experimental code, you never need to backtrack, you never need to work on more than one portion of the code at a time - this is isomorphous. The rest of the time, it's not. CVS & SVN try to stretch the first abstraction to take care of these differences, but fail. git makes you face up to the fact that your abstractions are wrong.
- moe 16y ago
  No, it means you're using the wrong abstraction. It seems a large number of users prefers to work at a different level of abstraction than git requires. git makes you face up to the fact that your abstractions are wrong. Strangely mercurial tackles the exact same abstractions, yet has a much friendlier user-interface. The standard-rebuttal at this point will be "Fine, use mercurial then". I wonder if, at some point, more users will start doing that than the git-community would like. I, for one, am certainly tempted, but have so far held out due to the switching cost and because hg is, of course, not without flaws either. However, I don't think this "If it hurts then you're doing it wrong"-attitude can be healthy for git in the longterm. A bad user-interface remains a bad user-interface, no matter how you spin it. The big problem I see is not even with git currently having this bad user-interface, but rather with the widespread reluctance in git-circles to even think about ways to improve it.
jwhite 16y ago
You make valid points about open source tools frequently having leaky abstractions, and I often have exactly the same response that you do -- "Why don't people make more effort to make this elegant/pretty/intuitive?" But the more I use git, the more I actually appreciate the fact that the abstraction is leaky. When I'm manipulating my history, I often really _want_ to have all the guts hanging out so that I can slice and dice them. If git wasn't designed using the "composable tools" idea [1] then it would make this stuff a lot harder. The tradeoff is that it makes the learning curve a lot steeper. I understand that some developers don't want to know too much about their VCS, but I can't count the number of times when I have appreciated having an in depth knowledge of it [2]. I said this here once before, and I don't mind repeating it: git is a power tool for power users. It is also designed as VCS toolbox, so anyone who wants to write a more intuitive UI layered on top of git is welcome to. There are a couple out there, but they don't seem popular. I'm not sure why. [1] Although this phrase also conjures the UNIX Hater's Handbook's take on it: "tools for fools" [2] The next question is how much of the time do I get into these situations _because_ the guts are hanging out? Is that the reason I need the power tools to get me out of trouble? It's hard to judge because I'm too close to the trees to see the forest on this issue.

tow21 16y ago

In other words, Git's abstraction is leaky No, it means you're using the wrong abstraction. As you change your codebase, files are modified. To the untrained eye, it looks like this a simple linear progression of history, and you just want to record savepoints as you go along. CVS lets you pretend this is the case. Actually, that's not the case at all. What you actually want to record is the changes you're making, and the relations between them. In the vanishingly small edge case where you never have any collaborators, never any experimental code, you never need to backtrack, you never need to work on more than one portion of the code at a time - this is isomorphous. The rest of the time, it's not. CVS & SVN try to stretch the first abstraction to take care of these differences, but fail. git makes you face up to the fact that your abstractions are wrong.

moe 16y ago
No, it means you're using the wrong abstraction. It seems a large number of users prefers to work at a different level of abstraction than git requires. git makes you face up to the fact that your abstractions are wrong. Strangely mercurial tackles the exact same abstractions, yet has a much friendlier user-interface. The standard-rebuttal at this point will be "Fine, use mercurial then". I wonder if, at some point, more users will start doing that than the git-community would like. I, for one, am certainly tempted, but have so far held out due to the switching cost and because hg is, of course, not without flaws either. However, I don't think this "If it hurts then you're doing it wrong"-attitude can be healthy for git in the longterm. A bad user-interface remains a bad user-interface, no matter how you spin it. The big problem I see is not even with git currently having this bad user-interface, but rather with the widespread reluctance in git-circles to even think about ways to improve it.

jwhite 16y ago

You make valid points about open source tools frequently having leaky abstractions, and I often have exactly the same response that you do -- "Why don't people make more effort to make this elegant/pretty/intuitive?" But the more I use git, the more I actually appreciate the fact that the abstraction is leaky. When I'm manipulating my history, I often really _want_ to have all the guts hanging out so that I can slice and dice them. If git wasn't designed using the "composable tools" idea [1] then it would make this stuff a lot harder. The tradeoff is that it makes the learning curve a lot steeper. I understand that some developers don't want to know too much about their VCS, but I can't count the number of times when I have appreciated having an in depth knowledge of it [2]. I said this here once before, and I don't mind repeating it: git is a power tool for power users. It is also designed as VCS toolbox, so anyone who wants to write a more intuitive UI layered on top of git is welcome to. There are a couple out there, but they don't seem popular. I'm not sure why. [1] Although this phrase also conjures the UNIX Hater's Handbook's take on it: "tools for fools" [2] The next question is how much of the time do I get into these situations _because_ the guts are hanging out? Is that the reason I need the power tools to get me out of trouble? It's hard to judge because I'm too close to the trees to see the forest on this issue.