4 ms·

>> most notably in games development, semiconductors and financial services are still using legacy tools like SVN and Perforce I think this should be your elev

>> most notably in games development, semiconductors and financial services are still using legacy tools like SVN and Perforce I think this should be your elevator pitch. Don't focus too much on "git complexity" as most people already know git so it just creates an argument. Scalability, in terms of numbers of users is somewhat hard to argue as well (Linux kernel has 1000s of contributors). However, it is completely true that git does not natively handle large binary assets well. You can even quote Linus: "I really don't know what to do about huge files. We suck at them, I know."

oblio 3y ago
> Don't focus too much on "git complexity" as most people already know git so it just creates an argument. I'd say this phrase is both right and wrong. It's right in the sense that it creates an argument. It's wrong in that it creates an argument with the peanut gallery of git experts. But guess what, most people using git are not experts. They're software developers who don't want to learn the intricacies of git (probably most software developers out there), they're software development adjacent folks (think data scientists, etc) who for sure don't want to learn the intricacies of git, etc. The "common person" using git will most likely resonate on the "git complexity" argument.
- osigurdson 3y ago
  It is just a tough argument to make: the thing you have been using for your entire career and used almost everywhere is suddenly too complex.
  - oblio 3y ago
    Ummm... A lot of people just endure using git. Go to the average enterprise software shop, the ones where people don't code for fun in their spare time, and ask around. There are a lot more of those devs than unicorn and FAANG devs.
    - osigurdson 3y ago
      Why aren't these teams choosing something else then? If everyone on the team dislikes git, switch to mercurial or something else.
      - sasham 3y ago
        Git might be the best thing there is today (outside of very large companies or environments with large binaries). It doesn't mean that'll always be the case... There were other VCSs before git, and there will be after.
      - layer8 3y ago
        Because often it’s not the team that chooses, but tooling is instead standardized across the enterprise. And enterprises like to make the “safe” choice of choosing what’s most popular. And then there’s the whole aspect that you have to know some basic Git anyway to debug your way through the open source code you use (maybe not for JavaScript/NPM, I don’t know). Git also happens to currently be the most interoperable with other kinds of tooling, from CI to IDEs, so not using Git makes your life harder in ways unrelated to its inherent qualities. It’s a network effect in multiple dimensions.
        osigurdson 3y ago
        How did it get so popular if disliked by the majority of dev?
        stackskipton 3y ago
        Because generally people picking the tools are not majority of dev. They are architects or Senior Developers who do enjoy learning new things. Also, git generally does just work and most IDE/Source Control Systems take care of basic operation of pull/branch/commit/push/open PR.
        osigurdson 3y ago
  - bigstrat2003 3y ago
    I use git because other people use git, and ultimately I try to accommodate the tools that my peers are going to be used to. But I do think it's too complex (by a lot), and if I was running some kind of dictatorship I would never touch git again. Frankly, I think that git is a significantly worse tool than svn was for most use cases.
    - osigurdson 3y ago
      I like git better than svn personally. But, svn is better at managing large binary files.
- withinboredom 3y ago
  Learn your tools or one day you’ll lose a finger, or worse, your life. — high school shop class
  - oblio 3y ago
    Yet software is not a chainsaw and a huge amount of people never learn to use their software tools. Especially since they're 100x more complex than hardware tools and nobody has time to master everything.
    - withinboredom 3y ago
      If you are using a chainsaw in a wood shop, you are probably doing something wrong. The saying “learn your tools” means to spend some time learning your options and what is available to you, learning the “gotchas” and why. Woodworking tools are rather complex with “gotchas” that will kill you in less than a hundred ms. Using Git isn’t much more complex than using a lathe (simpler even, as you can get by with no skill and rote memorization). Taking a weekend to learn the data structures, and how everything fits together is not a hard ask. Especially since you literally only have to do it once in your entire career.
      - oblio 3y ago
        > Taking a weekend to learn the data structures, and how everything fits together is not a hard ask. Especially since you literally only have to do it once in your entire career. Like all simplifications, this is false. If all you do for years after is commit, push, merge, you'll forget. Especially since you'll need those brain cells to learn the new CPU/GPU architecture, the new JavaScript framework, the new corporate security policy, the docs from your internal architecture team, etc. Nobody's life revolves around intricate VCS details.
        withinboredom 3y ago
        You don’t need to memorize it for life. Jeez man, don’t be so hard on yourself. The point is, you know what is possible. You know what is impossible. 12 years later, something happens and you go … hmm, I used to know what is going on. I think I need to search for something about git-tree or something? The point is, you know what to search for, a starting point. You don’t just reach for git cherry-pick, but realize you can use git rebase --onto to copy/paste an entire branch. You don’t worry about merge conflicts because you only have to do it once with rerere. You learn git reflog will remind you what branch you were working on this morning before you got pulled into some shenanigans in prod. You can set up automation with global hooks. There’s so much you can know to do less work and you only need to remember the parts that are valuable to you. After learning git about 5 years ago stuff like ^ is all second nature to me, for nearly 10 years since switching from SVN. My first 5 years was just like you said. Commit, pull, commit, pull. I didn’t even know it could do anything else and I was worse for it.
- philsnow 3y ago
  > peanut gallery of git experts There are people who use git for its original purpose (kernel devs and very few others) and then there is the remaining 99% of people who essentially use “github flavored git”, using only three or four git subcommands and for the most part never needing to understand its intricacies. Unfortunately, although they are using git-the-chainsaw-shotgun with all the safeties on, it’s nonetheless a chainsaw shotgun and sometimes they’ll run into issues where they or somebody in their company needs to be an expert and figure out how to un-scramble an egg, so to speak. If a new VCS can solve the 99% case and never need users to fall back to understanding nitty gritty details, it could very well have strong takeup especially among people who don’t give a crap about what VCS they’re using as long as it gets out of the way and doesn’t make them think (game devs, data folks, etc).
  - deleted 3y ago
    [deleted]
  - oblio 3y ago
    I see 2 huge barriers for a new commercial VCS: 1. Devs don't like to pay for core tools. And VCSes need network effects. 2. VCSes seem to be really hard.
    - gavinhoward 3y ago
      As someone who is making one (not Diversion), I agree with both of your points. Do you think that a VCS that solves the large file problem and binary file problem could succeed?
    - sasham 3y ago
      Totally agree, it won't be easy. Companies do pay for GitHub/GitLab/Perforce though, and for indie devs there's the free tier. I think what made git really take off is actually GitHub's free tier/OS hosting, and not git itself being free (at least for parts of the market, and I might be wrong). 100% correct about VCS development, it's much harder than one can expect.
      - 3y ago

oblio 3y ago

> Don't focus too much on "git complexity" as most people already know git so it just creates an argument. I'd say this phrase is both right and wrong. It's right in the sense that it creates an argument. It's wrong in that it creates an argument with the peanut gallery of git experts. But guess what, most people using git are not experts. They're software developers who don't want to learn the intricacies of git (probably most software developers out there), they're software development adjacent folks (think data scientists, etc) who for sure don't want to learn the intricacies of git, etc. The "common person" using git will most likely resonate on the "git complexity" argument.

osigurdson 3y ago
It is just a tough argument to make: the thing you have been using for your entire career and used almost everywhere is suddenly too complex.
- oblio 3y ago
  Ummm... A lot of people just endure using git. Go to the average enterprise software shop, the ones where people don't code for fun in their spare time, and ask around. There are a lot more of those devs than unicorn and FAANG devs.
  - osigurdson 3y ago
    Why aren't these teams choosing something else then? If everyone on the team dislikes git, switch to mercurial or something else.
    - sasham 3y ago
      Git might be the best thing there is today (outside of very large companies or environments with large binaries). It doesn't mean that'll always be the case... There were other VCSs before git, and there will be after.
    - layer8 3y ago
      Because often it’s not the team that chooses, but tooling is instead standardized across the enterprise. And enterprises like to make the “safe” choice of choosing what’s most popular. And then there’s the whole aspect that you have to know some basic Git anyway to debug your way through the open source code you use (maybe not for JavaScript/NPM, I don’t know). Git also happens to currently be the most interoperable with other kinds of tooling, from CI to IDEs, so not using Git makes your life harder in ways unrelated to its inherent qualities. It’s a network effect in multiple dimensions.
      - osigurdson 3y ago
        How did it get so popular if disliked by the majority of dev?
        stackskipton 3y ago
        Because generally people picking the tools are not majority of dev. They are architects or Senior Developers who do enjoy learning new things. Also, git generally does just work and most IDE/Source Control Systems take care of basic operation of pull/branch/commit/push/open PR.
        osigurdson 3y ago
- bigstrat2003 3y ago
  I use git because other people use git, and ultimately I try to accommodate the tools that my peers are going to be used to. But I do think it's too complex (by a lot), and if I was running some kind of dictatorship I would never touch git again. Frankly, I think that git is a significantly worse tool than svn was for most use cases.
  - osigurdson 3y ago
    I like git better than svn personally. But, svn is better at managing large binary files.
withinboredom 3y ago
Learn your tools or one day you’ll lose a finger, or worse, your life. — high school shop class
- oblio 3y ago
  Yet software is not a chainsaw and a huge amount of people never learn to use their software tools. Especially since they're 100x more complex than hardware tools and nobody has time to master everything.
  - withinboredom 3y ago
    If you are using a chainsaw in a wood shop, you are probably doing something wrong. The saying “learn your tools” means to spend some time learning your options and what is available to you, learning the “gotchas” and why. Woodworking tools are rather complex with “gotchas” that will kill you in less than a hundred ms. Using Git isn’t much more complex than using a lathe (simpler even, as you can get by with no skill and rote memorization). Taking a weekend to learn the data structures, and how everything fits together is not a hard ask. Especially since you literally only have to do it once in your entire career.
    - oblio 3y ago
      > Taking a weekend to learn the data structures, and how everything fits together is not a hard ask. Especially since you literally only have to do it once in your entire career. Like all simplifications, this is false. If all you do for years after is commit, push, merge, you'll forget. Especially since you'll need those brain cells to learn the new CPU/GPU architecture, the new JavaScript framework, the new corporate security policy, the docs from your internal architecture team, etc. Nobody's life revolves around intricate VCS details.
      - withinboredom 3y ago
        You don’t need to memorize it for life. Jeez man, don’t be so hard on yourself. The point is, you know what is possible. You know what is impossible. 12 years later, something happens and you go … hmm, I used to know what is going on. I think I need to search for something about git-tree or something? The point is, you know what to search for, a starting point. You don’t just reach for git cherry-pick, but realize you can use git rebase --onto to copy/paste an entire branch. You don’t worry about merge conflicts because you only have to do it once with rerere. You learn git reflog will remind you what branch you were working on this morning before you got pulled into some shenanigans in prod. You can set up automation with global hooks. There’s so much you can know to do less work and you only need to remember the parts that are valuable to you. After learning git about 5 years ago stuff like ^ is all second nature to me, for nearly 10 years since switching from SVN. My first 5 years was just like you said. Commit, pull, commit, pull. I didn’t even know it could do anything else and I was worse for it.
philsnow 3y ago
> peanut gallery of git experts There are people who use git for its original purpose (kernel devs and very few others) and then there is the remaining 99% of people who essentially use “github flavored git”, using only three or four git subcommands and for the most part never needing to understand its intricacies. Unfortunately, although they are using git-the-chainsaw-shotgun with all the safeties on, it’s nonetheless a chainsaw shotgun and sometimes they’ll run into issues where they or somebody in their company needs to be an expert and figure out how to un-scramble an egg, so to speak. If a new VCS can solve the 99% case and never need users to fall back to understanding nitty gritty details, it could very well have strong takeup especially among people who don’t give a crap about what VCS they’re using as long as it gets out of the way and doesn’t make them think (game devs, data folks, etc).
- deleted 3y ago
  [deleted]
- oblio 3y ago
  I see 2 huge barriers for a new commercial VCS: 1. Devs don't like to pay for core tools. And VCSes need network effects. 2. VCSes seem to be really hard.
  - gavinhoward 3y ago
    As someone who is making one (not Diversion), I agree with both of your points. Do you think that a VCS that solves the large file problem and binary file problem could succeed?
  - sasham 3y ago
    Totally agree, it won't be easy. Companies do pay for GitHub/GitLab/Perforce though, and for indie devs there's the free tier. I think what made git really take off is actually GitHub's free tier/OS hosting, and not git itself being free (at least for parts of the market, and I might be wrong). 100% correct about VCS development, it's much harder than one can expect.
    - 3y ago