6 ms·

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

by Espressosaurus 3y ago

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!

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!