5 ms·

My Problem with Git: No Abstraction

29 points by dogweather 15y ago

lunaru 15y ago
Git reminds me of the Churchill quote on democracy. It's the worst form of version control system except all the others that have been tried. Despite putting up with arcane incantations, I'm not going back.
- wmf 15y ago
  Is Git actually better than Mercurial[1], or did it just win because Linus forced it on people? [1] Properly answering this requires imagining an alternative history where all the massive ecosystem was built around Hg instead.
  - mindstab 15y ago
    I suspect something in the magic of the execution of github has also helped a lot. Maybe it's the strong focus on social ontop of code and storage or something else but that site has probably helped a lot. Then again, even before that many big projects were falling to git from the likes of svn like Xorg and others. So it's hard to say. Maybe going back to the mailing lists of some of the big conversations might help shed more light. But yes, usually what can make a piece of software great is having some good applications, and the linux kernel was a great place for git to grow up and show off on. Maybe mercurial just suffered from less of that. Mind share seems to grow exponentially.
  - pyre 15y ago
    I don't know how active the Mercurial mailing list is, but the git mailing list was hugely active when I was on it back in 2008/2009. I can only imagine that it's gotten bigger over time. I imagine that to some extent that had at least something to do with it (though I don't claim that it was 100% of the cause).
  - micro_cam 15y ago
    If you wish to do something like import a large svn project you will find that git is dramatically faster and doesn't require you to build/acquire svn with swig bindings.
  - cdavid 15y ago
    I do think git is better than mercurial in significant ways, at least how it was circa 2010: - tag handling in hg is (was ?) horrible - I think using integers for revisions, even if just in the UI is a very confusing feature, as it gives a false sense of familiarity (hg like every DVCS I know internally uses unique ids for revisions). - too many ways to do branching that all have +/-. While you can do it in a similar way to git, you don't have all the UI that makes it so useful. - the notion of tip is a major UI wart as well. On the + for mercurial: definitely better support for cross platform, more consistant UI, better performances on windows.
  - jsight 15y ago
    I think there are tons of reasons to prefer Mercurial over git (ease of use on Windows in the early days being a big one). I also think there are a smaller number of potentially more significant reasons to prefer git. But I think it's almost completely impossible to separate the success of Git from the tools ecosystem. I really think Mercurial would have been at least as popular as git in the long run if it had something as good as Github behind it from the beginning. The benefits of Github are truly astounding.
    - wmf 15y ago
      Which then makes me wonder why they chose to start GitHub instead of HgHub. Rails may have been the reason; I'm not sure when or why Rails started using git.
  - dogweather 15y ago
    I'm using git because Github exists. Otherwise, I'd be checking out Mercurial.
deleted 15y ago
[deleted]
GilK 15y ago
Legit already solves some of those problems http://www.git-legit.org/ http://www.git-legit.org/
wmf 15y ago
The problem with git wrappers is that there are a dozen of them but none have critical mass, so all docs and examples are written in terms of bare git. It's like CoffeeScript — it's fine if you already know JS and use it to save time, but you can't use it as a way to avoid learning JS.
- dogweather 15y ago
  Interesting. Yeah, I was afraid that was the case. I'm starting my own wrapper for better or worse. Maybe I'm just being blindly naive. https://github.com/dogweather/g https://github.com/dogweather/g I'm attempting to first spec it out in an appropriate way: writing the docs first, and so that the new abstraction is maintained. However, the new commands should re-use git command knowledge and not change it arbitrarily. It should fail well.
- natep 15y ago
  Which is why I'm a bit saddened to see another wrapper start up. Does OP even know about them, or does he think he's the first person to have the idea of creating a git porcelain? And then there's always that 1 time you need to do something that git can do, but your porcelain can't. Then you have no choice but to learn git the 'right' way. Personally, I think I understand git too well for picking up a porcelain to be useful to me, which also makes me a bit sad.
  - dogweather 15y ago
    I admit it - I don't know about any other higher level command line wrappers. I've only found hub http://defunkt.io/hub/ http://defunkt.io/hub/ which isn't exactly what I'm thinking of. Ah hah - I've found just one, although it looks pretty good http://www.git-legit.org/ http://www.git-legit.org/
platz 15y ago
http://blog.nelhage.com/2010/01/on-git-and-usability/ http://blog.nelhage.com/2010/01/on-git-and-usability/ "Fundamentally, the way (most) people learn and think about subversion is different from the way git experts think about git. subversion’s internal model is fairly complex, but you are not expected to understand it. You just have to know the half dozen commands you’ll ever need, and you use them, and everything is fine. Git’s model is fundamentally fairly simple (a DAG of immutable commit objects where branches are named mutable pointers into it), but you are expected to understand it fully to use git effectively." ... " The other, perhaps more fundamental reason, is that git is designed to be infinitely flexible, and so it’s fairly rare that you can give an answer for “How do I do X with git?”, since the answer will often depend on, “Well, what are your project’s conventions?” "
ww520 15y ago
Is Git really that hard to use? I've used ClearCase, Perforce, CVS, SVN, and Git. They all have their benefits and idiosyncrasies. Git is not that hard. I do have to search for its usage and example from time to time for less frequently used commands, but that's the same for the others.
- rogerbinns 15y ago
  The problem with git is that its defaults are suited to large teams collaborating. For example if you create tags then push won't push them unless you specify another flag. This makes sense when there are lots of collaborators (you don't want everyone's tags polluting) but is annoying in small groups (you do want to share). This isn't to fault git, but it is what makes it harder to use. I'm also confused by the github love. Exactly what is it that people think is so good about it? The ticket tracker is terrible (no prioritization, no attachments), the wiki doesn't have table of contents/document structure, you can't cross link between projects etc. As an example Google Code does quite a bit better on those issues, and they let you have multiple repositories per project so you can share the wiki, tracker and downloads as makes sense.
billsix 15y ago
I don't understand how "mv", with relative and absolute pathnames, is implementation leakage.
- fr0sty 15y ago
  Maybe it is a UNIX/non-UNIX thing... I have been using UNIX-type operating systems almost exclusively for the whole of my professional life so have zero appreciation for the troubles people have when approaching UNIX tools from a Windows (or whatever) mindset. Git (and the whole toolchain and OS for that matter) is much more about DWIS than DWIM and that does not click for a lot of people.
  - dogweather 15y ago
    No, it's not about mindset or command-line unix culture. It's about interface design. The command line interface. All of the established unix commands do a particular conceptual thing well. "sort" always sorts. Its options affect how it sorts. But git ... "git checkout" can switch the working branch. "git checkout" can rollback code ... depending on the specified options.
- lubutu 15y ago
  As much as I agree with the rest of the article, I have no idea what is meant by this "implementation leakage". Relative and absolute paths are a part of the fundamental Unix interface.
- i_s 15y ago
  What he was getting at with that is the conflation of moving and renaming files. He would want "mv" to take 2 params: (1) old file path (e.g., "/users/dev/foo.clj", and (2) new directory (e.g., "/users/lib").
  - dogweather 15y ago
    For me personally, mv doesn't actually bother me. But yes, for this discussion, a higher level version would probably split it into two commands: rename and move. And these would only do those particular functions. With that there is no implementation leakage. For the few times that you'd want to move and rename, you'd need to use both commands.
jgv 15y ago
The author suggests aliases and while I use aliases daily, I don't believe that will solve the problem he references. I think providing a better mental model for what exactly git is doing through visual metaphors is the biggest help to those learning git. I've found something as simple as the chart here to help explain the concepts of adding and staging http://gitready.com/beginner/2009/01/18/the-staging-area.html http://gitready.com/beginner/2009/01/18/the-staging-area.htm...
jerf 15y ago
Part of why I like git is the lack of abstraction. Lack of abstraction means the abstraction that isn't there can't leak. I've done some bizarre things in git, mostly induced by the fact the company I'm working for is still on SVN in the core. For instance, on two fundamentally different machines based on the same source tree, I developed a shared feature on one, bundled it all up into one commit, put some work into integrating it on the other, put some more work on the original and bundled it up into one new unified commit, pulled from the second machine and did an interactive rebase to slide the new megacommit under the integration commits. And it all worked perfectly and exactly as I expected, complete with dead-on accurate merge conflicts that truly were conflicts. If you had problems following that description, well, git didn't. Yes, to the extent that may seem like a bizarre workflow, it is. I know. There are additional constraints I did not describe. The point is, it's a workflow that git doesn't close off with leaky or over-limiting abstractions. That said, I totally agree that this is irreducibly a strength and a weakness at the same time, and YMWV. But I'm glad it's around so I can use it. It's saved my bacon more times than I can count.
- dogweather 15y ago
  For sure, it's nice to have both available: high level and low level. Like Ubunutu's user-add and add-user. (Of course, those are horribly named.)
- platz 15y ago
  In other words, perhaps git is like C
Apreche 15y ago
Git is a Hole Hawg, just like UNIX. That's intentional. Stop trying to change the software to be easier. Instead change yourself. Make yourself stronger and better by learning this complicated stuff, and become a master. You can't drive a car with a manual, the solution isn't to get an automatic. The solution is to learn to drive stick. For those unfamiliar with the Hole Hawg: http://steve-parker.org/articles/others/stephenson/holehawg.shtml http://steve-parker.org/articles/others/stephenson/holehawg....
- jaylevitt 15y ago
  Great story about the Hole Hawg, but... I've had two houses built. For about five years, I spent 8-12 hours a day with some of the best contractors in Massachusetts. I never saw a Hole Hawg. I kinda wonder if that's the story you tell yourself to explain why you were hanging in midair from a drill.
  - fr0sty 15y ago
    The Hole Hawg is quite real, actually: http://www.milwaukeetool.com/tools/drills/hole-hawgs http://www.milwaukeetool.com/tools/drills/hole-hawgs
- sopooneo 15y ago
  I think I take your point, but we should only put up with having to learn necessarily complicated things. So to the extent that the Git interface reflects a powerful and flexible internal model, I'm with you. But Git is also unnecessarily complicated. The commands are inconsistent and hard to remember until you have them by rote. That's a failure of software design.
  - fr0sty 15y ago
    "That's a failure of software design." Or the evidence of a differing opinion on what amount of complexity is necessary.
Cogito 15y ago
In the project's README it says "g add isn't necessary for staging since g commit will automatically add objects. In fact, g does not expose the concept of staging through its interface", which if followed through with will ensure that this project never gains traction. The staging areas, though foreign to newcomers, is one of the most liked features of git (I should look up the git survey results, but I'm lazy). In fact, it is core to many excellent features of git, not least of all the ability to interactively select which parts of your work you want to commit, even down to different hunks in the same file. Ignoring this powerful concept makes git a less powerful beast, and hobbles it unnecessarily. To say that the concept of staging is complex is fine, but surely throwing it out is the wrong answer.
- dogweather 15y ago
  Interesting feedback - thanks! I started off with that idea because I personally rarely use this feature. I pretty much always commit all my changes. And so I only change things that I want to commit. I'm sure I picked up this habit from my svn days. I'll look around for those survey results.
jonpaul 15y ago
Shameful plug: http://gitpilot.com http://gitpilot.com We seek to fix the abstraction aspect by focusing on the difficult of collaboration. It's working really well for us. We'll be launching our beta test soon.

29 points by dogweather 15y ago

Git reminds me of the Churchill quote on democracy. It's the worst form of version control system except all the others that have been tried. Despite putting up with arcane incantations, I'm not going back.

wmf 15y ago
Is Git actually better than Mercurial[1], or did it just win because Linus forced it on people? [1] Properly answering this requires imagining an alternative history where all the massive ecosystem was built around Hg instead.
- mindstab 15y ago
  I suspect something in the magic of the execution of github has also helped a lot. Maybe it's the strong focus on social ontop of code and storage or something else but that site has probably helped a lot. Then again, even before that many big projects were falling to git from the likes of svn like Xorg and others. So it's hard to say. Maybe going back to the mailing lists of some of the big conversations might help shed more light. But yes, usually what can make a piece of software great is having some good applications, and the linux kernel was a great place for git to grow up and show off on. Maybe mercurial just suffered from less of that. Mind share seems to grow exponentially.
- pyre 15y ago
  I don't know how active the Mercurial mailing list is, but the git mailing list was hugely active when I was on it back in 2008/2009. I can only imagine that it's gotten bigger over time. I imagine that to some extent that had at least something to do with it (though I don't claim that it was 100% of the cause).
- micro_cam 15y ago
  If you wish to do something like import a large svn project you will find that git is dramatically faster and doesn't require you to build/acquire svn with swig bindings.
- cdavid 15y ago
  I do think git is better than mercurial in significant ways, at least how it was circa 2010: - tag handling in hg is (was ?) horrible - I think using integers for revisions, even if just in the UI is a very confusing feature, as it gives a false sense of familiarity (hg like every DVCS I know internally uses unique ids for revisions). - too many ways to do branching that all have +/-. While you can do it in a similar way to git, you don't have all the UI that makes it so useful. - the notion of tip is a major UI wart as well. On the + for mercurial: definitely better support for cross platform, more consistant UI, better performances on windows.
- jsight 15y ago
  I think there are tons of reasons to prefer Mercurial over git (ease of use on Windows in the early days being a big one). I also think there are a smaller number of potentially more significant reasons to prefer git. But I think it's almost completely impossible to separate the success of Git from the tools ecosystem. I really think Mercurial would have been at least as popular as git in the long run if it had something as good as Github behind it from the beginning. The benefits of Github are truly astounding.
  - wmf 15y ago
    Which then makes me wonder why they chose to start GitHub instead of HgHub. Rails may have been the reason; I'm not sure when or why Rails started using git.
- dogweather 15y ago
  I'm using git because Github exists. Otherwise, I'd be checking out Mercurial.

deleted 15y ago

[deleted]

GilK 15y ago

Legit already solves some of those problems http://www.git-legit.org/ http://www.git-legit.org/

wmf 15y ago

The problem with git wrappers is that there are a dozen of them but none have critical mass, so all docs and examples are written in terms of bare git. It's like CoffeeScript — it's fine if you already know JS and use it to save time, but you can't use it as a way to avoid learning JS.

dogweather 15y ago
Interesting. Yeah, I was afraid that was the case. I'm starting my own wrapper for better or worse. Maybe I'm just being blindly naive. https://github.com/dogweather/g https://github.com/dogweather/g I'm attempting to first spec it out in an appropriate way: writing the docs first, and so that the new abstraction is maintained. However, the new commands should re-use git command knowledge and not change it arbitrarily. It should fail well.
natep 15y ago
Which is why I'm a bit saddened to see another wrapper start up. Does OP even know about them, or does he think he's the first person to have the idea of creating a git porcelain? And then there's always that 1 time you need to do something that git can do, but your porcelain can't. Then you have no choice but to learn git the 'right' way. Personally, I think I understand git too well for picking up a porcelain to be useful to me, which also makes me a bit sad.
- dogweather 15y ago
  I admit it - I don't know about any other higher level command line wrappers. I've only found hub http://defunkt.io/hub/ http://defunkt.io/hub/ which isn't exactly what I'm thinking of. Ah hah - I've found just one, although it looks pretty good http://www.git-legit.org/ http://www.git-legit.org/

platz 15y ago

http://blog.nelhage.com/2010/01/on-git-and-usability/ http://blog.nelhage.com/2010/01/on-git-and-usability/ "Fundamentally, the way (most) people learn and think about subversion is different from the way git experts think about git. subversion’s internal model is fairly complex, but you are not expected to understand it. You just have to know the half dozen commands you’ll ever need, and you use them, and everything is fine. Git’s model is fundamentally fairly simple (a DAG of immutable commit objects where branches are named mutable pointers into it), but you are expected to understand it fully to use git effectively." ... " The other, perhaps more fundamental reason, is that git is designed to be infinitely flexible, and so it’s fairly rare that you can give an answer for “How do I do X with git?”, since the answer will often depend on, “Well, what are your project’s conventions?” "

ww520 15y ago

Is Git really that hard to use? I've used ClearCase, Perforce, CVS, SVN, and Git. They all have their benefits and idiosyncrasies. Git is not that hard. I do have to search for its usage and example from time to time for less frequently used commands, but that's the same for the others.

rogerbinns 15y ago
The problem with git is that its defaults are suited to large teams collaborating. For example if you create tags then push won't push them unless you specify another flag. This makes sense when there are lots of collaborators (you don't want everyone's tags polluting) but is annoying in small groups (you do want to share). This isn't to fault git, but it is what makes it harder to use. I'm also confused by the github love. Exactly what is it that people think is so good about it? The ticket tracker is terrible (no prioritization, no attachments), the wiki doesn't have table of contents/document structure, you can't cross link between projects etc. As an example Google Code does quite a bit better on those issues, and they let you have multiple repositories per project so you can share the wiki, tracker and downloads as makes sense.

billsix 15y ago

I don't understand how "mv", with relative and absolute pathnames, is implementation leakage.

fr0sty 15y ago
Maybe it is a UNIX/non-UNIX thing... I have been using UNIX-type operating systems almost exclusively for the whole of my professional life so have zero appreciation for the troubles people have when approaching UNIX tools from a Windows (or whatever) mindset. Git (and the whole toolchain and OS for that matter) is much more about DWIS than DWIM and that does not click for a lot of people.
- dogweather 15y ago
  No, it's not about mindset or command-line unix culture. It's about interface design. The command line interface. All of the established unix commands do a particular conceptual thing well. "sort" always sorts. Its options affect how it sorts. But git ... "git checkout" can switch the working branch. "git checkout" can rollback code ... depending on the specified options.
lubutu 15y ago
As much as I agree with the rest of the article, I have no idea what is meant by this "implementation leakage". Relative and absolute paths are a part of the fundamental Unix interface.
i_s 15y ago
What he was getting at with that is the conflation of moving and renaming files. He would want "mv" to take 2 params: (1) old file path (e.g., "/users/dev/foo.clj", and (2) new directory (e.g., "/users/lib").
- dogweather 15y ago
  For me personally, mv doesn't actually bother me. But yes, for this discussion, a higher level version would probably split it into two commands: rename and move. And these would only do those particular functions. With that there is no implementation leakage. For the few times that you'd want to move and rename, you'd need to use both commands.

jgv 15y ago

The author suggests aliases and while I use aliases daily, I don't believe that will solve the problem he references. I think providing a better mental model for what exactly git is doing through visual metaphors is the biggest help to those learning git. I've found something as simple as the chart here to help explain the concepts of adding and staging http://gitready.com/beginner/2009/01/18/the-staging-area.html http://gitready.com/beginner/2009/01/18/the-staging-area.htm...

jerf 15y ago

Part of why I like git is the lack of abstraction. Lack of abstraction means the abstraction that isn't there can't leak. I've done some bizarre things in git, mostly induced by the fact the company I'm working for is still on SVN in the core. For instance, on two fundamentally different machines based on the same source tree, I developed a shared feature on one, bundled it all up into one commit, put some work into integrating it on the other, put some more work on the original and bundled it up into one new unified commit, pulled from the second machine and did an interactive rebase to slide the new megacommit under the integration commits. And it all worked perfectly and exactly as I expected, complete with dead-on accurate merge conflicts that truly were conflicts. If you had problems following that description, well, git didn't. Yes, to the extent that may seem like a bizarre workflow, it is. I know. There are additional constraints I did not describe. The point is, it's a workflow that git doesn't close off with leaky or over-limiting abstractions. That said, I totally agree that this is irreducibly a strength and a weakness at the same time, and YMWV. But I'm glad it's around so I can use it. It's saved my bacon more times than I can count.

dogweather 15y ago
For sure, it's nice to have both available: high level and low level. Like Ubunutu's user-add and add-user. (Of course, those are horribly named.)
platz 15y ago
In other words, perhaps git is like C

Apreche 15y ago

Git is a Hole Hawg, just like UNIX. That's intentional. Stop trying to change the software to be easier. Instead change yourself. Make yourself stronger and better by learning this complicated stuff, and become a master. You can't drive a car with a manual, the solution isn't to get an automatic. The solution is to learn to drive stick. For those unfamiliar with the Hole Hawg: http://steve-parker.org/articles/others/stephenson/holehawg.shtml http://steve-parker.org/articles/others/stephenson/holehawg....

jaylevitt 15y ago
Great story about the Hole Hawg, but... I've had two houses built. For about five years, I spent 8-12 hours a day with some of the best contractors in Massachusetts. I never saw a Hole Hawg. I kinda wonder if that's the story you tell yourself to explain why you were hanging in midair from a drill.
- fr0sty 15y ago
  The Hole Hawg is quite real, actually: http://www.milwaukeetool.com/tools/drills/hole-hawgs http://www.milwaukeetool.com/tools/drills/hole-hawgs
sopooneo 15y ago
I think I take your point, but we should only put up with having to learn necessarily complicated things. So to the extent that the Git interface reflects a powerful and flexible internal model, I'm with you. But Git is also unnecessarily complicated. The commands are inconsistent and hard to remember until you have them by rote. That's a failure of software design.
- fr0sty 15y ago
  "That's a failure of software design." Or the evidence of a differing opinion on what amount of complexity is necessary.

Cogito 15y ago

In the project's README it says "g add isn't necessary for staging since g commit will automatically add objects. In fact, g does not expose the concept of staging through its interface", which if followed through with will ensure that this project never gains traction. The staging areas, though foreign to newcomers, is one of the most liked features of git (I should look up the git survey results, but I'm lazy). In fact, it is core to many excellent features of git, not least of all the ability to interactively select which parts of your work you want to commit, even down to different hunks in the same file. Ignoring this powerful concept makes git a less powerful beast, and hobbles it unnecessarily. To say that the concept of staging is complex is fine, but surely throwing it out is the wrong answer.

dogweather 15y ago
Interesting feedback - thanks! I started off with that idea because I personally rarely use this feature. I pretty much always commit all my changes. And so I only change things that I want to commit. I'm sure I picked up this habit from my svn days. I'll look around for those survey results.

jonpaul 15y ago

Shameful plug: http://gitpilot.com http://gitpilot.com We seek to fix the abstraction aspect by focusing on the difficult of collaboration. It's working really well for us. We'll be launching our beta test soon.