5 ms·

Thanks! We're definitely not trying to bash Git, it's done a lot of good for software development and for sure is going to continue evolving. Git had much more

by sasham 3y ago

Thanks! We're definitely not trying to bash Git, it's done a lot of good for software development and for sure is going to continue evolving. Git had much more edge when it was competing vs SVN and other centralized VCSs. With 10Mb networks (if you were in office) you could feel physical pain when committing stuff >< Reg how Git is not perfect in the cloud world - check out GitHub's blog post here about their cloud dev environment, Codespaces https://github.blog/2021-08-11-githubs-engineering-team-moved-codespaces/ https://github.blog/2021-08-11-githubs-engineering-team-move... "The GitHub.com repository is almost 13 GB on disk; simply cloning the repository takes 20 minutes." Moving 13GB inside your own cloud should take seconds at most. The problem is the way Git works, it clones your entire repository into the container with your cloud environment, using a slow network protocol. With Diversion it takes a few seconds.

dartos 3y ago
> We're definitely not trying to bash Git Using git with bash is the best way to use git (:
- gnarlouse 3y ago
  Came here to make a similar joke
andsoitis 3y ago
> Thanks! We're definitely not trying to bash Git, it's done a lot of good for software development and for sure is going to continue evolving. It is not about bashing git; it is about anchoring your argument of why Diversion is a better alternative around git. You're basically taking your game/arguments to their playing field, and thus will have an uphill battle for mindshre. Instead, consider reframing the playing field and mention git less (if at all). Something like "the future of version control is blah". Surprise us, talk to us about your vision for source control, or better yet, code and multi-discipline collaboration (e.g. between eng and design), etc.
- bruh2 3y ago
  I personally would not bother reading any "the future of X" if it did not address problems of existing tools. I know you're trying to give advice from a marketing pov, and it is good, but it's also inherently bulshitty – because its purpose is to net more sales rather than actually make a good argument
asimpletune 3y ago
I'm not sure I understand this at all. > The problem is the way Git works, it clones your entire repository into the container with your cloud environment, using a slow network protocol. What about git's network protocol is 'slow'? I think I can also come up with a pretty simple experiment to prove or disprove this: 1. Fill a file with 13Gb of data and commit it. 2. Upload that to GitHub or wherever you want 3. Time how long it takes to clone and compare that to the real GitHub.com You will find the one we made takes 'seconds' (or minutes, depending on your network connection), while the the GitHub.com will take some time. So, same data, two different results? The difference in this experiment rules out the 'slow' network protocol as the difference maker. The real reason is that the GitHub.com repo will have hundreds or thousands of commits. Basically, the difference is the commit history, because that's how git needs to work. Git stores the diffs for the entire commit history, not just the literal files at the HEAD. I don't know what the network protocol has to do with that.
- yjftsjthsd-h 3y ago
  It is perhaps worth pointing out that if you don't need the history you can just `git clone --depth 1` and save the network transfer and disk space.
  - TexasMick 3y ago
    It reminds of when someone told me git submodules are slow. They just forgot about shallow clones..
- nolist_policy 3y ago
  If you use the dumb http protocol, both cases should be equally fast.
  - asimpletune 3y ago
    git clone https://github.com/github/docs.git https://github.com/github/docs.git 123.57s user 37.02s system 74% cpu 3:35.73 total git clone --depth 1 https://github.com/github/docs.git https://github.com/github/docs.git 3.37s user 1.83s system 35% cpu 14.521 total Not a scientific test at all, but the second one was literally 15x faster, wall clock time.
funcDropShadow 3y ago
That article also states that using a standard Git feature, shallow clones, you go from 20min to 90s. Most of the problems touched upon in the article are about state management for local environments, yes that can be tricky. And it can take time, but it has nothing to do with Git.

by sasham 3y ago

dartos 3y ago

> We're definitely not trying to bash Git Using git with bash is the best way to use git (:

gnarlouse 3y ago
Came here to make a similar joke

andsoitis 3y ago

> Thanks! We're definitely not trying to bash Git, it's done a lot of good for software development and for sure is going to continue evolving. It is not about bashing git; it is about anchoring your argument of why Diversion is a better alternative around git. You're basically taking your game/arguments to their playing field, and thus will have an uphill battle for mindshre. Instead, consider reframing the playing field and mention git less (if at all). Something like "the future of version control is blah". Surprise us, talk to us about your vision for source control, or better yet, code and multi-discipline collaboration (e.g. between eng and design), etc.

bruh2 3y ago
I personally would not bother reading any "the future of X" if it did not address problems of existing tools. I know you're trying to give advice from a marketing pov, and it is good, but it's also inherently bulshitty – because its purpose is to net more sales rather than actually make a good argument

asimpletune 3y ago

I'm not sure I understand this at all. > The problem is the way Git works, it clones your entire repository into the container with your cloud environment, using a slow network protocol. What about git's network protocol is 'slow'? I think I can also come up with a pretty simple experiment to prove or disprove this: 1. Fill a file with 13Gb of data and commit it. 2. Upload that to GitHub or wherever you want 3. Time how long it takes to clone and compare that to the real GitHub.com You will find the one we made takes 'seconds' (or minutes, depending on your network connection), while the the GitHub.com will take some time. So, same data, two different results? The difference in this experiment rules out the 'slow' network protocol as the difference maker. The real reason is that the GitHub.com repo will have hundreds or thousands of commits. Basically, the difference is the commit history, because that's how git needs to work. Git stores the diffs for the entire commit history, not just the literal files at the HEAD. I don't know what the network protocol has to do with that.

yjftsjthsd-h 3y ago
It is perhaps worth pointing out that if you don't need the history you can just `git clone --depth 1` and save the network transfer and disk space.
- TexasMick 3y ago
  It reminds of when someone told me git submodules are slow. They just forgot about shallow clones..
nolist_policy 3y ago
If you use the dumb http protocol, both cases should be equally fast.
- asimpletune 3y ago
  git clone https://github.com/github/docs.git https://github.com/github/docs.git 123.57s user 37.02s system 74% cpu 3:35.73 total git clone --depth 1 https://github.com/github/docs.git https://github.com/github/docs.git 3.37s user 1.83s system 35% cpu 14.521 total Not a scientific test at all, but the second one was literally 15x faster, wall clock time.

funcDropShadow 3y ago

That article also states that using a standard Git feature, shallow clones, you go from 20min to 90s. Most of the problems touched upon in the article are about state management for local environments, yes that can be tricky. And it can take time, but it has nothing to do with Git.