8 ms·

Yes. Git is powerful, but sadly has deep problems in its conceptual design. This is the reason why even mid-level engineers don't understand it fully. Love thi

by hackpr 8y ago

Yes. Git is powerful, but sadly has deep problems in its conceptual design. This is the reason why even mid-level engineers don't understand it fully. Love this work!

arximboldi 8y ago
Can you elaborate on the deep problems? I personally find it relatively conceptually elegant.
- fgonzag 8y ago
  I think the main problem is that many developers don't think of Git as a DAG, so they don't really understand at a fundamental level what the operations are actually doing. Once you understand this, Git really does become simple. All you have to do is map each command to the actual operation on the DAG. This video really explains it quite well, it's the one video that allowed me to fully grasp everything: https://www.youtube.com/watch?v=1ffBJ4sVUb4 https://www.youtube.com/watch?v=1ffBJ4sVUb4
  - bauerd 8y ago
    Yeah, but the question is whether a DAG is a good mental model for a VCS. Just because that's the underlying data structure doesn't mean it has to be the user interface too.
    - bachmeier 8y ago
      Exactly. This seems to be a point that the "Git is easy" crew doesn't understand. Not everyone (in fact, very few) find going into that depth for something that's nothing more than a tool to be reasonable. Reminds me of the Gentoo users that used to say compiling everything is a great idea for an OS.
      - jungler 8y ago
        I find that people understand "linearized" concepts easier than other kinds(DAGs included). When elements are left-to-right or top-to-bottom, you can read what is going on at a glance. So the next major step in VCS technology will most likely do something to help linearize our views and reduce the tangling that comes into play with any tree or graph structure.
        __blockcipher__ 8y ago
        Don’t we already have that in some respects? a) Most people’s git workflow might as well be linear. b) rebasing a development branch onto master literally linearizes it Where git shines though of course is where you can’t get away witha linear model
  - ruseOps 8y ago
    A big part of learning anything is understanding - at a fundamental level - what operations are being executed by whichever tool is being utilized. So if you will pardon the paraphrase, I think the main problem is that many developers don’t take the time to simply learn git.
- paulddraper 8y ago
  I compare it to 10-15 years ago, when functional programming was rather rare. Mid-level OO programmers would complain it was confusing and unfamilar, whereas in reality has beautiful and simple concepts. Git's use of a DAG is confusing and unfamilar for many programmers, though in reality it's beautiful and simple.
  - bachmeier 8y ago
    > Git's use of a DAG is confusing and unfamilar for many programmers, though in reality it's beautiful and simple. The difference relative to functional programming is that you get paid for one and the other is just a tool
    - adambyrtek 8y ago
      I would argue that functional programming is just a tool as well... Programmers are paid for solving problems and code is just a means to that end.
    - deleted 8y ago
      [deleted]
  - glitchc 8y ago
    Yup, second that. My old boss introduced the whole team to Scala and made us attend a weekly tutorial as part of training/team-building. Since then, I try to write stateless functions, methods and objects as much as possible regardless of language or platform. Git is quite elegant if one has a good grasp of graph theory.
    - Fins 8y ago
      Git is certainly great technically. But one should not need to know graph theory to source control files. And I believe that any version control system that does not follow the convention (that probably predates Linus' existence on Earth) that commit should actually commit changes to server, is, by definition, more4 hard to use than it has any reason to be. But this might be a good study in why Linux is not taking over the desktop, and unlikely to do so in foreseeable future.
- apichat 8y ago
  I think that you can find good explanations of these problems here : https://jneem.github.io/merging/ https://jneem.github.io/merging/ https://pijul.org/model/#why-care-about-patch-theory https://pijul.org/model/#why-care-about-patch-theory Unfortunatly Gitless doesn't solve them. But Pijul solve many problems of Git (and Darcs) and is easier to use. https://pijul.org https://pijul.org
  - pantalaimon 8y ago
    It appears as https://nest.pijul.com/pijul_org/pijul https://nest.pijul.com/pijul_org/pijul is currently being hugged to death?
    - apichat 8y ago
      It's ok now. They published a new version of Pijul and it seems that it cause some problems. https://pijul.org/posts/2018-11-20-pijul-0.11/ https://pijul.org/posts/2018-11-20-pijul-0.11/ https://pijul.org/posts/2018-04-21-pijul-0.10/ https://pijul.org/posts/2018-04-21-pijul-0.10/
    - Nzen 8y ago
      It's a once a month / once a quarter occurance. I'm not sure if it's because of changes to the webservice or not enough financial backing. I've basically given up on using early access pijul. I've had a problem with each of the last three versions, primarily pushing to Nest. It wouldn't be an issue if I could install pijul on NearlyFreeSpeech (because then I could self host on a known good version). I want pijul to succeed, its patching model sounds good. Clearly, it's working for some group of people. But I'm not one of them, and it's past where I feel like I'm wasting my time. I'll try again when they're v1.0
scrollaway 8y ago
Gitless doesn't change anything about git's concepts, it just abstracts away some commands. So if you think this solves the problems, they're clearly not "conceptual" faults. I think this is important because people are so quick to jump on the "git is bad" contrarian meme. Git is a fantastic piece of work and the CLI has a variety of issues. On top of this, git is conceptually unintuitive, so the CLI issues make for a worse experience.
- joshuamorton 8y ago
  The other half of the issue is that git's commands don't follow the abstraction. If each command mapped to a single dag operation, it might make more sense. But they don't (revert).
  - 4lch3m1st 8y ago
    They shouldn't. I'm not saying that Git doesn't have commands that can be hard to understand fully, but the whole point of any abstraction is to hide the "insides" of any operation so you don't have to think about them. Having commands for each DAG operation will just add more complexity and expose a structure which you shouldn't be handling manually.
    - sofal 8y ago
      I think in order to really feel comfortable with Git you have reverse that and think about the DAG as the actual interface and the CLI as the clunky implementation you use to modify the DAG.
sigsergv 8y ago
Git design is surprisingly clean and simple. The main issue of git is its CLI and commands naming. They are indeed unclear. But again, concept behind is absolutely amazing. You just need to understand that git repo is a series of snapshots and after that all other details become clear.
- reacweb 8y ago
  Naming is difficult. Good names suggest the right metaphore to understand something. But for git, there is nothing similar in physical world. "push" "pull" and "merge" seem ok, but even "branch" is an original concept different of its usual meaning. Maybe git should have used non english words to avoid confusion.
  - icebraining 8y ago
    Branch seems to fit the dictionary definition: "something that extends from or enters into a main body or source". And in fact, it didn't originate with git, it's at least as old as CVS.
    - reacweb 8y ago
      http://lmgtfy.com/?q=git+what+is+a+branch http://lmgtfy.com/?q=git+what+is+a+branch "A branch in Git is simply a lightweight movable pointer to one of these commits." https://git-scm.com/book/en/v1/Git-Branching-What-a-Branch-Is https://git-scm.com/book/en/v1/Git-Branching-What-a-Branch-I...

by hackpr 8y ago

Yes. Git is powerful, but sadly has deep problems in its conceptual design. This is the reason why even mid-level engineers don't understand it fully. Love this work!

arximboldi 8y ago

Can you elaborate on the deep problems? I personally find it relatively conceptually elegant.

fgonzag 8y ago
I think the main problem is that many developers don't think of Git as a DAG, so they don't really understand at a fundamental level what the operations are actually doing. Once you understand this, Git really does become simple. All you have to do is map each command to the actual operation on the DAG. This video really explains it quite well, it's the one video that allowed me to fully grasp everything: https://www.youtube.com/watch?v=1ffBJ4sVUb4 https://www.youtube.com/watch?v=1ffBJ4sVUb4
- bauerd 8y ago
  Yeah, but the question is whether a DAG is a good mental model for a VCS. Just because that's the underlying data structure doesn't mean it has to be the user interface too.
  - bachmeier 8y ago
    Exactly. This seems to be a point that the "Git is easy" crew doesn't understand. Not everyone (in fact, very few) find going into that depth for something that's nothing more than a tool to be reasonable. Reminds me of the Gentoo users that used to say compiling everything is a great idea for an OS.
    - jungler 8y ago
      I find that people understand "linearized" concepts easier than other kinds(DAGs included). When elements are left-to-right or top-to-bottom, you can read what is going on at a glance. So the next major step in VCS technology will most likely do something to help linearize our views and reduce the tangling that comes into play with any tree or graph structure.
      - __blockcipher__ 8y ago
        Don’t we already have that in some respects? a) Most people’s git workflow might as well be linear. b) rebasing a development branch onto master literally linearizes it Where git shines though of course is where you can’t get away witha linear model
- ruseOps 8y ago
  A big part of learning anything is understanding - at a fundamental level - what operations are being executed by whichever tool is being utilized. So if you will pardon the paraphrase, I think the main problem is that many developers don’t take the time to simply learn git.
paulddraper 8y ago
I compare it to 10-15 years ago, when functional programming was rather rare. Mid-level OO programmers would complain it was confusing and unfamilar, whereas in reality has beautiful and simple concepts. Git's use of a DAG is confusing and unfamilar for many programmers, though in reality it's beautiful and simple.
- bachmeier 8y ago
  > Git's use of a DAG is confusing and unfamilar for many programmers, though in reality it's beautiful and simple. The difference relative to functional programming is that you get paid for one and the other is just a tool
  - adambyrtek 8y ago
    I would argue that functional programming is just a tool as well... Programmers are paid for solving problems and code is just a means to that end.
  - deleted 8y ago
    [deleted]
- glitchc 8y ago
  Yup, second that. My old boss introduced the whole team to Scala and made us attend a weekly tutorial as part of training/team-building. Since then, I try to write stateless functions, methods and objects as much as possible regardless of language or platform. Git is quite elegant if one has a good grasp of graph theory.
  - Fins 8y ago
    Git is certainly great technically. But one should not need to know graph theory to source control files. And I believe that any version control system that does not follow the convention (that probably predates Linus' existence on Earth) that commit should actually commit changes to server, is, by definition, more4 hard to use than it has any reason to be. But this might be a good study in why Linux is not taking over the desktop, and unlikely to do so in foreseeable future.
apichat 8y ago
I think that you can find good explanations of these problems here : https://jneem.github.io/merging/ https://jneem.github.io/merging/ https://pijul.org/model/#why-care-about-patch-theory https://pijul.org/model/#why-care-about-patch-theory Unfortunatly Gitless doesn't solve them. But Pijul solve many problems of Git (and Darcs) and is easier to use. https://pijul.org https://pijul.org
- pantalaimon 8y ago
  It appears as https://nest.pijul.com/pijul_org/pijul https://nest.pijul.com/pijul_org/pijul is currently being hugged to death?
  - apichat 8y ago
    It's ok now. They published a new version of Pijul and it seems that it cause some problems. https://pijul.org/posts/2018-11-20-pijul-0.11/ https://pijul.org/posts/2018-11-20-pijul-0.11/ https://pijul.org/posts/2018-04-21-pijul-0.10/ https://pijul.org/posts/2018-04-21-pijul-0.10/
  - Nzen 8y ago
    It's a once a month / once a quarter occurance. I'm not sure if it's because of changes to the webservice or not enough financial backing. I've basically given up on using early access pijul. I've had a problem with each of the last three versions, primarily pushing to Nest. It wouldn't be an issue if I could install pijul on NearlyFreeSpeech (because then I could self host on a known good version). I want pijul to succeed, its patching model sounds good. Clearly, it's working for some group of people. But I'm not one of them, and it's past where I feel like I'm wasting my time. I'll try again when they're v1.0

scrollaway 8y ago

Gitless doesn't change anything about git's concepts, it just abstracts away some commands. So if you think this solves the problems, they're clearly not "conceptual" faults. I think this is important because people are so quick to jump on the "git is bad" contrarian meme. Git is a fantastic piece of work and the CLI has a variety of issues. On top of this, git is conceptually unintuitive, so the CLI issues make for a worse experience.

joshuamorton 8y ago
The other half of the issue is that git's commands don't follow the abstraction. If each command mapped to a single dag operation, it might make more sense. But they don't (revert).
- 4lch3m1st 8y ago
  They shouldn't. I'm not saying that Git doesn't have commands that can be hard to understand fully, but the whole point of any abstraction is to hide the "insides" of any operation so you don't have to think about them. Having commands for each DAG operation will just add more complexity and expose a structure which you shouldn't be handling manually.
  - sofal 8y ago
    I think in order to really feel comfortable with Git you have reverse that and think about the DAG as the actual interface and the CLI as the clunky implementation you use to modify the DAG.

sigsergv 8y ago

Git design is surprisingly clean and simple. The main issue of git is its CLI and commands naming. They are indeed unclear. But again, concept behind is absolutely amazing. You just need to understand that git repo is a series of snapshots and after that all other details become clear.

reacweb 8y ago
Naming is difficult. Good names suggest the right metaphore to understand something. But for git, there is nothing similar in physical world. "push" "pull" and "merge" seem ok, but even "branch" is an original concept different of its usual meaning. Maybe git should have used non english words to avoid confusion.
- icebraining 8y ago
  Branch seems to fit the dictionary definition: "something that extends from or enters into a main body or source". And in fact, it didn't originate with git, it's at least as old as CVS.
  - reacweb 8y ago
    http://lmgtfy.com/?q=git+what+is+a+branch http://lmgtfy.com/?q=git+what+is+a+branch "A branch in Git is simply a lightweight movable pointer to one of these commits." https://git-scm.com/book/en/v1/Git-Branching-What-a-Branch-Is https://git-scm.com/book/en/v1/Git-Branching-What-a-Branch-I...