4 ms·

I agree. Just based on the number of tutorials and posts about how Git is difficult / hard / weird Seems to me that Git is more complicated than it should be.

by elviejo 13y ago

I agree. Just based on the number of tutorials and posts about how Git is difficult / hard / weird Seems to me that Git is more complicated than it should be. I mean code repository as a software developer is an essential tool it should be as intuitive to use as a text editor. PS: Also the common answers to "Git is complicated" are symptom to me that is harder than it should be 1. "Git is not version control is an application framework" well since it only has a version control build into it I say thay are the same. 2. "Git is difficult but it enables you do to really powerful stuff" Here I quote Kay: 'Simple things should be simple, complex things should be possible.' Seems to me that git took the approach complex things are complex and simple things are complex too! 3. "You just don't understand Git's model" Well many programmers barely understand what a compiler does yet they are capable of writing software. 4. "You just haven't invested the time it takes to master git" I have seen posts from developers working with Git that still can only do the most basic stuff. Those are the same excuses used for previous technologies just replace git with: Java threads (before Go, Erlang) OOP (before Java, Smalltalk) Functional Programming (before haskell, F#) In each case when the tool was correct the paradigm became obvious.

mtdewcmu 13y ago
Well said. I feel that complaints from users should always be taken seriously. The fact that a piece of software is better than what came before doesn't mean that it can't have flaws, and can't be improved upon. I don't think git's command-line interface was designed poorly or to make things difficult. What I think is that the command-line interface was created as an afterthought, since git was originally supposed to be a low-level component and not a full-fledged VCS, and so the commands were cobbled together rather than planned.
MBCook 13y ago
> 3. "You just don't understand Git's model" Well many programmers barely understand what a compiler does yet they are capable of writing software. I really do think this is the issue. I've been using git for about a year, but I was never confused about what it was doing because I understood it. I eagerly watched the developed back when the whole Bitkeeper thing came to a head. Not only did I see the start, I saw the situation it was born in. Git is a uni-directional acyclic graph for tracking patches. Git was designed around the model the Linux kernel had used, sending patch sets around. You merge people's patch sets in, you re-base an existing patch set on the current development, you figure out what the difference is. Since Git tracks all those patches (which everyone calls commits), it has a full history of them. That history is a simple graph that always moves forward. The distributed stuff (like origins, remotes, etc) is just a way of formalizing all the "look at my tree" stuff that the kernel guys did. The basic model really is quite simple (the command line certainly has a few warts), the distributed stuff makes a fair amount of sense, and the patches aspect fits in really well. I think the problem is that most people come to it from the CVS/SVN model. Commits in those systems are more permanent, where as the patches floating around the LKML were always more ephemeral; you could try to apply them at any point if you could fix the merge issues. I actually wonder if borrowing so much of the existing version control system vocabulary made things worse. Commits are patches. 'Staging' is the stuff you haven't send to the mailing list yet. Branches are long series of patches. Merging is accepting patches, and re-basing is apply a patch set against a different starting point. If you go straight from "This is what CVS does" to "This is what Git does", you miss why Git works like that. Whenever your mental model doesn't match reality (in this case, how Git operates) you end up with frustration and confusion.
- teacup50 13y ago
  Or, you understand why git works the way it does, but since you don't work on the Linux kernel and don't consider your code ephemeral, you find git's tooling to be be incredibly frustrating and complex to use when all you want or need is a safe, immutable version control system.
  - MBCook 13y ago
    I will say, I only use the command line for a few things like rebasing. 99% of my work is done in SourceTree which is incredibly easy to use.
- wpietri 13y ago
  Thanks, this is helpful. In designing things for users, I think a lot about the difference between meaning and mechanism. In early computers, you were confronted with a lot of mechanism: switches to flip, magnetic media to treat worshipfully, mysterious incantations to type. But something like the iPad, the surface interactions are mainly about meaning. When you say, "Git is a uni-directional acyclic graph for tracking patches," I believe you, and I believe that's how people like Linus think of it. But that's mostly mechanism. For people who were soaking in large open source projects, I think that mechanism reflects their meaning pretty well. But for people putting stuff on the web, or building internal tools, it's very different. The base case is, "thing that is live now," and "thing that will be live soon". Patches? Don't need 'em. For those people (which I think is the bulk of developers today), they are forced to deal with a lot of git's mechanism, to no real benefit. If git had been designed to be a popular VCS, I'd call that a design mistake. But I think it's hard to claim that; as you say, git makes sense in its original context.
  - MBCook 13y ago
    Well, saying "Git is a uni-directional acyclic graph for tracking patches" is a bit like saying "Monads are endofunctors in the domain of (whatever)". It doesn't really explain things unless the audience is really heavily into CS. Despite the available complexity, you can choose to ignore most of it without issue. If you use a good client (I like SourceTree) you can avoid the command line's warts and some things like staging and remotes become more clear. When we switched to Git, I had my team (pretty small) basically treat Git like SVN for a little while. Once they got comfortable with that, it was easy to explain some of the differences (like local/remote) and they could quickly pick up the rest.
eru 13y ago
> I mean code repository as a software developer is an essential tool it should be as intuitive to use as a text editor. Git's no harder to use than vim.
- recursive 13y ago
  Sick burn.
polemic 13y ago
> "Just based on the number of tutorials and posts about how Git is difficult / hard / weird" So.. not from actually using it then? Git is as complex as you need it to be. Much of the 'complexity' in the post is functionality that you can use to make your life easier if you so wish. And if you don't want to use it, don't. Telling other people their their tool that does everything they need it to do is too complicated? Nup.

by elviejo 13y ago

mtdewcmu 13y ago

Well said. I feel that complaints from users should always be taken seriously. The fact that a piece of software is better than what came before doesn't mean that it can't have flaws, and can't be improved upon. I don't think git's command-line interface was designed poorly or to make things difficult. What I think is that the command-line interface was created as an afterthought, since git was originally supposed to be a low-level component and not a full-fledged VCS, and so the commands were cobbled together rather than planned.

MBCook 13y ago

> 3. "You just don't understand Git's model" Well many programmers barely understand what a compiler does yet they are capable of writing software. I really do think this is the issue. I've been using git for about a year, but I was never confused about what it was doing because I understood it. I eagerly watched the developed back when the whole Bitkeeper thing came to a head. Not only did I see the start, I saw the situation it was born in. Git is a uni-directional acyclic graph for tracking patches. Git was designed around the model the Linux kernel had used, sending patch sets around. You merge people's patch sets in, you re-base an existing patch set on the current development, you figure out what the difference is. Since Git tracks all those patches (which everyone calls commits), it has a full history of them. That history is a simple graph that always moves forward. The distributed stuff (like origins, remotes, etc) is just a way of formalizing all the "look at my tree" stuff that the kernel guys did. The basic model really is quite simple (the command line certainly has a few warts), the distributed stuff makes a fair amount of sense, and the patches aspect fits in really well. I think the problem is that most people come to it from the CVS/SVN model. Commits in those systems are more permanent, where as the patches floating around the LKML were always more ephemeral; you could try to apply them at any point if you could fix the merge issues. I actually wonder if borrowing so much of the existing version control system vocabulary made things worse. Commits are patches. 'Staging' is the stuff you haven't send to the mailing list yet. Branches are long series of patches. Merging is accepting patches, and re-basing is apply a patch set against a different starting point. If you go straight from "This is what CVS does" to "This is what Git does", you miss why Git works like that. Whenever your mental model doesn't match reality (in this case, how Git operates) you end up with frustration and confusion.

teacup50 13y ago
Or, you understand why git works the way it does, but since you don't work on the Linux kernel and don't consider your code ephemeral, you find git's tooling to be be incredibly frustrating and complex to use when all you want or need is a safe, immutable version control system.
- MBCook 13y ago
  I will say, I only use the command line for a few things like rebasing. 99% of my work is done in SourceTree which is incredibly easy to use.
wpietri 13y ago
Thanks, this is helpful. In designing things for users, I think a lot about the difference between meaning and mechanism. In early computers, you were confronted with a lot of mechanism: switches to flip, magnetic media to treat worshipfully, mysterious incantations to type. But something like the iPad, the surface interactions are mainly about meaning. When you say, "Git is a uni-directional acyclic graph for tracking patches," I believe you, and I believe that's how people like Linus think of it. But that's mostly mechanism. For people who were soaking in large open source projects, I think that mechanism reflects their meaning pretty well. But for people putting stuff on the web, or building internal tools, it's very different. The base case is, "thing that is live now," and "thing that will be live soon". Patches? Don't need 'em. For those people (which I think is the bulk of developers today), they are forced to deal with a lot of git's mechanism, to no real benefit. If git had been designed to be a popular VCS, I'd call that a design mistake. But I think it's hard to claim that; as you say, git makes sense in its original context.
- MBCook 13y ago
  Well, saying "Git is a uni-directional acyclic graph for tracking patches" is a bit like saying "Monads are endofunctors in the domain of (whatever)". It doesn't really explain things unless the audience is really heavily into CS. Despite the available complexity, you can choose to ignore most of it without issue. If you use a good client (I like SourceTree) you can avoid the command line's warts and some things like staging and remotes become more clear. When we switched to Git, I had my team (pretty small) basically treat Git like SVN for a little while. Once they got comfortable with that, it was easy to explain some of the differences (like local/remote) and they could quickly pick up the rest.

eru 13y ago

> I mean code repository as a software developer is an essential tool it should be as intuitive to use as a text editor. Git's no harder to use than vim.

recursive 13y ago
Sick burn.

polemic 13y ago

> "Just based on the number of tutorials and posts about how Git is difficult / hard / weird" So.. not from actually using it then? Git is as complex as you need it to be. Much of the 'complexity' in the post is functionality that you can use to make your life easier if you so wish. And if you don't want to use it, don't. Telling other people their their tool that does everything they need it to do is too complicated? Nup.