4 ms·

My dream is that someday we’ll all use a VCS that is so simple the internet doesn’t have literally tens of thousands of blog posts pretending it’s simple. Somed

My dream is that someday we’ll all use a VCS that is so simple the internet doesn’t have literally tens of thousands of blog posts pretending it’s simple. Someday…

Espressosaurus 3y ago
We had our chance and decided that worse is better, so here we are.
- IshKebab 3y ago
  Mercurial was simpler but it was also written in slooooow Python so overall it wasn't really better.
  - forrestthewoods 3y ago
    Re-implementing a good API in a better language is relatively easy. Replacing a bad API is nigh impossible. :( Mistakes were made.
    - memefrog 3y ago
      It is easy to replace a "bad API". There are a million alternative CLIs and GUIs for git. They haven't caught on because it turns out git's CLI isnt actually bad. It feels complex because it feels like what it is doing is simpler than is presented. But in fact it is solving quite a complicated distributed database program, transactionally, with editable history. The CLI hides a lot of that but cant hide it all. But you do need the flexibility.
      - forrestthewoods 3y ago
        Hard disagree. Perforce is idiot proof. I can teach a non-programmer who has never even heard of revision control how to use Perforce in literally 10 minutes. They will never shoot themselves in the foot. They will never lose work. They will never, ever need to nuke and reclone their repo. Perforce has other issues of course. But Git has both a bad CLI and a bad model. Maybe its particular model is strictly required for the Linux kernel. However for 99% of developers that are centralized on GitHub the model ranges from “mediocre fit” to “downright broken”.
        PaulDavisThe1st 3y ago
        > Perforce is idiot proof. > Perforce has other issues of course. Claim: You can't solve the issues with perforce without making it no longer idiot proof. I've used perforce. For distributed development, it's a total non-starter.
        whartung 3y ago
        Just curious about this because I’ve never had any direct experience. All of my uses of any version control (save very early work with RCS) has been to a central server. But “distributed” must mean something other than that, especially how git is presented (i.e. technically there is no center). So, do folks doing distributed development routinely push changes in a peer to peer fashion? Alice, Bob, and Charlene are collaborating with Alice and Bob working on one feature while Alice and Charlene work on another, pushing incremental changes to each other but only sending the completed feature/branch to their non-collaborating peers when they’re complete. Does that happen often or is it just the “commit early, commit often to the local copy” that distributed devs are really using? “I can edit on a plane” scenarios.
        memefrog 3y ago
        >So, do folks doing distributed development routinely push changes in a peer to peer fashion? Alice, Bob, and Charlene are collaborating with Alice and Bob working on one feature while Alice and Charlene work on another, pushing incremental changes to each other but only sending the completed feature/branch to their non-collaborating peers when they’re complete. Yes. The prototypical example is the Linux kernel, which is what git was originally created for. There, there are a large number of different trees. Linus's tree is 'standard' Linux, but there are the various stable trees, there are trees for various subsystems, there's the continuous integration tree 'linux-next', and others. Those trees' changes are all intended to eventually reach Linus's tree. But there are other trees which aren't, they host patchsets that sit on top of Linux "proper" but aren't intended to ever be upstreamed. >Does that happen often or is it just the “commit early, commit often to the local copy” that distributed devs are really using? “I can edit on a plane” scenarios. In practice, not many open source projects are big enough and distributed enough that they need to do what Linux does. This aspect of it is very useful too: that you can code on a plane, that you can code in the bath, that you can code in a shack in the woods, etc.
    - IshKebab 3y ago
      So relatively simple that it took 12 years to even begin? Can you really blame people for using Git when it took them 9 years to even accept that Python performance was a problem? https://mail.python.org/pipermail/python-dev/2014-May/134528.html https://mail.python.org/pipermail/python-dev/2014-May/134528...
- mardifoufs 3y ago
  I'm curious, if you are referring to mercurial, how is it better? I've never used it so I'm wondering what I'm "missing out" on!
IshKebab 3y ago
I think it's because it is simple, but Git's terrible CLI makes it hard to learn. Once you've learnt it you can ignore all of the terrible interface and just think about the actual operations you want to do which are generally very simple. I could explain Git's data model and what the operations do to my wife. I don't think I could actually teach her how to use the git command line though.
- Pxtl 3y ago
  The core is simple. Misfeatures like the stage and the stash and submodules are not part of the simple core. The workflow where we have no good way to hide history besides destroying it is simple but also stupid, particularly when destroying history also destroys your ability to collaborate or even merge your own code cleanly.
  - PaulDavisThe1st 3y ago
    You'll get your hands on my git stash when I'm dead and buried and turned to dust in the ground. Not to worry, you'll probably still be alive for that.
  - IshKebab 3y ago
    Staging area and stash are simple too. Here I'll explain it in 10 seconds: * The staging area/"index" is a draft commit. You can add or remove things to the draft. When you run `git commit` it turns the draft into a real commit and the draft becomes empty again. * Stashes are just "WIP" commits. They don't have a branch name pointing to them but you can list them all. When you apply or pop (apply & delete) a stash it takes the diff from the stash commit (versus its parent) and applies it to your working tree. Submodules conceptually are relatively simple but the actual implementation is stupidly buggy and confusing. Like, I still have no idea what "submodule init" does. Why are there two places where submodules are stored - `.gitmodules` and a second secret place that you can't see? Why isn't `--recursive` the default? Why doesn't switching branch also switch the submodules? Most of the answers to that are "well it could work properly and be simple, but actually it's half-arsed and full of bugs". You can seriously break your repo with `git switch --recursive` or if you try to use work trees with submodules.
PlunderBunny 3y ago
Yeah. Maybe I'm making excuses, but tools should be easy to use and get out of the way - they're not what we're being paid for. People say 'knowing how to use your tools properly is part of your craft', but I feel Git is more like someone asked for a cabinet and instead we gave them a hammer, some nails, and some timber and said 'but this is so much better than just giving you a cabinet!'
- sixstringtheory 3y ago
  I see it more like someone asked for a cabinet and hired you, the carpenter, to plane, route, chamfer, mitre, join, hammer, nail, screw and glue the wood into place. You absolutely need to know the right tools and techniques, of which there are many. For instance, nails and screws are not interchangeable, and they're made with a variety of metals and coatings for specific applications. Just about anyone can hammer a nail into a piece of wood. It is quite difficult to put together a high quality finished piece of woodwork. Same is true for software.
  - PlunderBunny 3y ago
    I can sort-of see your point, but (stretching the analogy way too far), imagine I'm the interior decorator and I'm asking for a cabinet among other things. My expertise is not in making the cabinet. Relating it back to being a software developer, my expertise is in the problem domain and the business logic. I don't think Git is stupid or fundamentally wrong, just that the interface we're all using (even the GUI interfaces) are just thin veneers over the underlying API, which is confusing to many people, and that Git could be more productive for most developers when we have an abstraction that is easier to understand. I've seen people much smarter than me fumbling around to solve problems with Git.
    - PaulDavisThe1st 3y ago
      > Relating it back to being a software developer, my expertise is in the problem domain and the business logic. That's your problem right there. You're a craftsman. You have three sets of inputs: raw materials, designs and tools. You've chosen to focus on raw materials and designs, and have decided that mastery of the tools (or some subset of the tools) is not important. A cabinet maker who said "my expertise is in complex corner joinery and standalone rectangular forms" would be laughed at if they also added "i find japanese saws and routers problematic". Yes, tools are tricky. Tools are hard. But tools are an equal part of the task triangle, and you owe it yourself to build up your own scaffolding of understanding for the tools as you do for the other components.
memefrog 3y ago
People blog about things they learn about. Lots of people use git so they blog about it. Nobody is pretending it is simple. It is simple.
- forrestthewoods 3y ago
  > It is simple. No, it isn’t.

My dream is that someday we’ll all use a VCS that is so simple the internet doesn’t have literally tens of thousands of blog posts pretending it’s simple. Someday…

Espressosaurus 3y ago

We had our chance and decided that worse is better, so here we are.

IshKebab 3y ago
Mercurial was simpler but it was also written in slooooow Python so overall it wasn't really better.
- forrestthewoods 3y ago
  Re-implementing a good API in a better language is relatively easy. Replacing a bad API is nigh impossible. :( Mistakes were made.
  - memefrog 3y ago
    It is easy to replace a "bad API". There are a million alternative CLIs and GUIs for git. They haven't caught on because it turns out git's CLI isnt actually bad. It feels complex because it feels like what it is doing is simpler than is presented. But in fact it is solving quite a complicated distributed database program, transactionally, with editable history. The CLI hides a lot of that but cant hide it all. But you do need the flexibility.
    - forrestthewoods 3y ago
      Hard disagree. Perforce is idiot proof. I can teach a non-programmer who has never even heard of revision control how to use Perforce in literally 10 minutes. They will never shoot themselves in the foot. They will never lose work. They will never, ever need to nuke and reclone their repo. Perforce has other issues of course. But Git has both a bad CLI and a bad model. Maybe its particular model is strictly required for the Linux kernel. However for 99% of developers that are centralized on GitHub the model ranges from “mediocre fit” to “downright broken”.
      - PaulDavisThe1st 3y ago
        > Perforce is idiot proof. > Perforce has other issues of course. Claim: You can't solve the issues with perforce without making it no longer idiot proof. I've used perforce. For distributed development, it's a total non-starter.
        whartung 3y ago
        Just curious about this because I’ve never had any direct experience. All of my uses of any version control (save very early work with RCS) has been to a central server. But “distributed” must mean something other than that, especially how git is presented (i.e. technically there is no center). So, do folks doing distributed development routinely push changes in a peer to peer fashion? Alice, Bob, and Charlene are collaborating with Alice and Bob working on one feature while Alice and Charlene work on another, pushing incremental changes to each other but only sending the completed feature/branch to their non-collaborating peers when they’re complete. Does that happen often or is it just the “commit early, commit often to the local copy” that distributed devs are really using? “I can edit on a plane” scenarios.
        memefrog 3y ago
        >So, do folks doing distributed development routinely push changes in a peer to peer fashion? Alice, Bob, and Charlene are collaborating with Alice and Bob working on one feature while Alice and Charlene work on another, pushing incremental changes to each other but only sending the completed feature/branch to their non-collaborating peers when they’re complete. Yes. The prototypical example is the Linux kernel, which is what git was originally created for. There, there are a large number of different trees. Linus's tree is 'standard' Linux, but there are the various stable trees, there are trees for various subsystems, there's the continuous integration tree 'linux-next', and others. Those trees' changes are all intended to eventually reach Linus's tree. But there are other trees which aren't, they host patchsets that sit on top of Linux "proper" but aren't intended to ever be upstreamed. >Does that happen often or is it just the “commit early, commit often to the local copy” that distributed devs are really using? “I can edit on a plane” scenarios. In practice, not many open source projects are big enough and distributed enough that they need to do what Linux does. This aspect of it is very useful too: that you can code on a plane, that you can code in the bath, that you can code in a shack in the woods, etc.
  - IshKebab 3y ago
    So relatively simple that it took 12 years to even begin? Can you really blame people for using Git when it took them 9 years to even accept that Python performance was a problem? https://mail.python.org/pipermail/python-dev/2014-May/134528.html https://mail.python.org/pipermail/python-dev/2014-May/134528...
mardifoufs 3y ago
I'm curious, if you are referring to mercurial, how is it better? I've never used it so I'm wondering what I'm "missing out" on!

IshKebab 3y ago

I think it's because it is simple, but Git's terrible CLI makes it hard to learn. Once you've learnt it you can ignore all of the terrible interface and just think about the actual operations you want to do which are generally very simple. I could explain Git's data model and what the operations do to my wife. I don't think I could actually teach her how to use the git command line though.

Pxtl 3y ago
The core is simple. Misfeatures like the stage and the stash and submodules are not part of the simple core. The workflow where we have no good way to hide history besides destroying it is simple but also stupid, particularly when destroying history also destroys your ability to collaborate or even merge your own code cleanly.
- PaulDavisThe1st 3y ago
  You'll get your hands on my git stash when I'm dead and buried and turned to dust in the ground. Not to worry, you'll probably still be alive for that.
- IshKebab 3y ago
  Staging area and stash are simple too. Here I'll explain it in 10 seconds: * The staging area/"index" is a draft commit. You can add or remove things to the draft. When you run `git commit` it turns the draft into a real commit and the draft becomes empty again. * Stashes are just "WIP" commits. They don't have a branch name pointing to them but you can list them all. When you apply or pop (apply & delete) a stash it takes the diff from the stash commit (versus its parent) and applies it to your working tree. Submodules conceptually are relatively simple but the actual implementation is stupidly buggy and confusing. Like, I still have no idea what "submodule init" does. Why are there two places where submodules are stored - `.gitmodules` and a second secret place that you can't see? Why isn't `--recursive` the default? Why doesn't switching branch also switch the submodules? Most of the answers to that are "well it could work properly and be simple, but actually it's half-arsed and full of bugs". You can seriously break your repo with `git switch --recursive` or if you try to use work trees with submodules.

PlunderBunny 3y ago

Yeah. Maybe I'm making excuses, but tools should be easy to use and get out of the way - they're not what we're being paid for. People say 'knowing how to use your tools properly is part of your craft', but I feel Git is more like someone asked for a cabinet and instead we gave them a hammer, some nails, and some timber and said 'but this is so much better than just giving you a cabinet!'

sixstringtheory 3y ago
I see it more like someone asked for a cabinet and hired you, the carpenter, to plane, route, chamfer, mitre, join, hammer, nail, screw and glue the wood into place. You absolutely need to know the right tools and techniques, of which there are many. For instance, nails and screws are not interchangeable, and they're made with a variety of metals and coatings for specific applications. Just about anyone can hammer a nail into a piece of wood. It is quite difficult to put together a high quality finished piece of woodwork. Same is true for software.
- PlunderBunny 3y ago
  I can sort-of see your point, but (stretching the analogy way too far), imagine I'm the interior decorator and I'm asking for a cabinet among other things. My expertise is not in making the cabinet. Relating it back to being a software developer, my expertise is in the problem domain and the business logic. I don't think Git is stupid or fundamentally wrong, just that the interface we're all using (even the GUI interfaces) are just thin veneers over the underlying API, which is confusing to many people, and that Git could be more productive for most developers when we have an abstraction that is easier to understand. I've seen people much smarter than me fumbling around to solve problems with Git.
  - PaulDavisThe1st 3y ago
    > Relating it back to being a software developer, my expertise is in the problem domain and the business logic. That's your problem right there. You're a craftsman. You have three sets of inputs: raw materials, designs and tools. You've chosen to focus on raw materials and designs, and have decided that mastery of the tools (or some subset of the tools) is not important. A cabinet maker who said "my expertise is in complex corner joinery and standalone rectangular forms" would be laughed at if they also added "i find japanese saws and routers problematic". Yes, tools are tricky. Tools are hard. But tools are an equal part of the task triangle, and you owe it yourself to build up your own scaffolding of understanding for the tools as you do for the other components.

memefrog 3y ago

People blog about things they learn about. Lots of people use git so they blog about it. Nobody is pretending it is simple. It is simple.

forrestthewoods 3y ago
> It is simple. No, it isn’t.