10 ms·

I have not analyzed the full potentials and benefits of Diversion but I would not agree with the statements you made about the Git. I think you should not focus

• Kiro 3y ago
  Git is bad for games and they should definitely compare them in their pitch if they want to capture that market.
  • kfrzcode 3y ago
    No, it's not. LFS has improved over the years. Git is supported as a first class citizen in Unreal Engine 5 - alongside P4.
    • Kiro 3y ago
      Good for developers using Unreal Engine 5 I guess. Fact remains that most game developers struggle with Git.
    • Arelius 3y ago
      Just because it has integrations, doesn't make it great. LFS is still not great. Doesn't have a lot of backends for instance. And a real locking system is table-stakes for a gamedev VCS
• funcDropShadow 3y ago
  Even a force push doesn't destroy the reflog or runs the GC server-side. I wonder how you can accidentally loose data with Git. I've seen lot's of people not being able to find it, but really destroying it is hard.
  • cqqxo4zV46cp 3y ago
    Destroying it and nobody knowing how to recover, or that it can be recovered at all, it are identical.
  • sasham 3y ago
    He force pushed a diverged branch or something like that, and we only found out after a while. We were eventually able to recover because someone didn't pull. But it was not a fun experience :D
    • School-Cotton 3y ago
      So the work wasn’t actually destroyed, and you were able to recover it. So all the people pointing out how implausible that part of your pitch was were right, and you were in fact just lying.
      • sasham 3y ago
        That's really not the main point of the post, but you're right I should have been more precise. Edit: updated in the top text now!
        • School-Cotton 3y ago
          [flagged]
        • ysavir 3y ago
          I think the point being made is that you spent a lot of your opening post talking Git, and lead with that bit, rather than with Diversion. What makes Diversion different is added in the end, after you've spent time trying to convince Git fans that their current tooling isn't good. Worse, the examples you listed of why Git is bad is more reflective of configuration and processes than Git itself. This is ultimately a very weak pitching strategy. The first thing you convey to your potential users is insecurity--an insecurity that people won't choose your product over Git. And it's hard to want to buy something from someone that isn't secure enough about their product to pitch the product first, and answer questions/make comparisons after, as a form of clarification. Alternatively, instead of doing a comparison to Git, you could start with a list of "have you experienced these Git issues? <list of problems>. Here's how Diversion improves on Git in this regard." In this case you're actually solving people's problems, rather than looking like you're grasping at straws to complain about Git and justify an alternative. FWIW, I personally have 0 interest in a cloud-first version control. I like the cloud as a form of backup and syncing with team members, but I ultimately want a version control that works as well offline as it does online, and prioritizes the local experience.
• Rygian 3y ago
  > This is mostly a configuration issue. I guess this was done by a force push command. IFAIK, you can disable force push by configuration. If a feature can lead to actual unintended data loss, it should come disabled by default. Are there any other "unsafe by default" features in Git? What would be a sane general default that prevents unwanted data loss, and why is it the case?
  • guax 3y ago
    --force always imply data loss. You're overriding the remote state. Do people use it in an unsafe manner because they don't understand git and there lies a problem that could be tackled? yes. With that, I don't think git has any feature that is unsafe by default.
    • sasham 3y ago
      In that specific case there was some error that the user didn't understand, he googled and found a StackOverflow answer with --force. And naturally tried it BitBucket didn't have branch protection back then, today it's a bit better (you can still destroy your work but usually not others')
      • nullstyle 3y ago
        This was Pebcac my dude. git wasn’t at fault here, the script kiddy that pastes before understanding is the fault. Amateurs
      • Einenlum 3y ago
        I agree that git is very complex (just try reading its documentation and how many options or commands you have never heard of before). But I think push --force is probably one of the easiest git concepts to get. The fact that someone in your team copy pasted something from SO without understanding it doesn't seem to be related to git. Otherwise we could say that the fact some people lose their data through "sudo rm -rf /" proves the complexity of Unix. I don't think so.
    • IshKebab 3y ago
• jsnell 3y ago
  > Slow network: why is this a negative thing? If something is designed for a slow network then it should perform well in a fast network. Designing for resource-constrained systems usually means you're making tradeoffs. If the resource constraint is removed, you're no longer getting the benefit of that tradeoff but are paying the costs. For example, TCP was designed for slow and unreliable networks. When networks got faster, the design decisions that made sense for slow networks (e.g. 32 bit sequence numbers, 16 bit window sizes) became untenable, and they had to spend effort on retrofitting the protocol to work around these restrictions (TCP timestamps, window scaling).
  • fourside 3y ago
    That makes sense but then the pitch should include something about how back in 2005 the design for git had to make a trade off because of X limitation, but now that restriction isn’t applicable which enables features A and B. I don’t really see what trade offs a faster network enables other than making it a requirement that you have a network connection to do work (commits are a REST call). I’m not sure that’s a trade off I’d want in my VCS, but maybe I’m just not the target audience for this.
• vintagedave 3y ago
  >> a data scientist accidentally destroyed a month’s work of his team > This is mostly a configuration issue git apologism :) (FWIW I do agree with the rest of your comment, and I hope you forgive the slight joke. Product users, for any product are fallible humans. That might be fallible in accidentally deleting, or it might be fallible in forgetting to turn on the safety settings.) Very seriously, something like this should not be possible in a source control system. Data integrity needs to be built in by design.
  • devjab 3y ago
    The issue with a lot of freedom and unopinionated tools is always going to be the multitude of ways to fuck up. On the flip-side, you may not like what choices are made if you’re forced to use it in a certain way. We enforce a strict pull-request squish commit with four eyes approval only. You can’t force push, you can’t rebase, you can’t not squish or whatever else you’d want to do. But we don’t pretend that is the “correct” way to use Git, we think it is, but who are we to tell you how to do you? We take a similar approach to how we use Typescript. We have our own library of coding “grammar?” that you have to follow if you want to commit TS into our pipelines. Again, we have a certain way to do things and you have to follow them, but these ways might not work for anyone else, and we do sometimes alter them a little if there is a good reason to do so. I don’t personally mind strict and opinionated software. I too think Git has far too many ways to fuck up, and that is far too easy to create a terrible work environment with JavaScript. It also takes a lot of initial effort to set rules up to make sure everyone works the same way. But again, what if the greater community decided that rebase was better than squash commit? Then we wouldn’t like Git, and I’m sure the rebase crowd feels the same way. The result would likely leave us with two Gits. Though I guess with initiatives like the launch here, is two Gits. So… well.
    • oblio 3y ago
      > But again, what if the greater community decided that rebase was better than squash commit? Then we wouldn’t like Git, and I’m sure the rebase crowd feels the same way. The result would likely leave us with two Gits. Meh, this is overrated. We'd end up with 2 Gits, and over time just one fork would probably take over, based on marketing, PR, dev team activity, etc. The second one would probably still be around but used by only a minor part of the community. Just because a thing has on paper many forks, does not mean those forks are equal. In fact, a situation with many major forks rarely survives the long term. See Jenkins vs Hudson, Firefox vs Iceweasel, etc. Most people will congregate towards one of the forks and that's it.
• 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
• IshKebab 3y ago
  > When Micorosoft adopted Git for Windows, they faced this problem and solved it. On Windows. On Linux Git still doesn't scale well to very large repos. Before you say "but Linux uses git!", we're talking repos that are much bugger than Linux. Also the de facto large file "solution" is LFS, which is another half baked idea that doesn't really do the job. You sound like you're offended that Git isn't perfect because you like it so much. But OP is 100% right here; these are things that Git doesn't do well. It's ok to really like something that isn't perfect. You don't have to defend flaws that it clearly has.
  • graemep 3y ago
    How common are repos bigger than Linux? Linux also has the huge advantage of an ecosystem, tools and integrations. It is overkill for small projects and there are friendlier alternatives for those - but git wins because it is what everyone knows. Something aimed at the small number of large projects will suffer the same problem.
    • gertop 3y ago
      > How common are repos bigger than Linux? In terms of number of commits, Linux is probably bigger than most. In terms of storage size, almost any video game project will be significantly bigger. It's no secret that git is very bad at handling large binary files.
      • Spivak 3y ago
        You don't even need game assets, your company's icon library is likely enough to tip the scales into territory git doesn't handle well.
      • graemep 3y ago
        So this is very specifically for things like games with large binary assets?
        • IshKebab 3y ago
• lifeofguenter 3y ago
  Have you ever tried running Git in the cloud? :) Cloud-native and running things on “EC2” are very different things.
  • sasham 3y ago
    Yep :) Lots of products run Git on EC2/containers, e.g. GitPod or GitHub Codespaces. Ironically, Diversion works much faster on these than git https://github.blog/2021-08-11-githubs-engineering-team-moved-codespaces/ https://github.blog/2021-08-11-githubs-engineering-team-move...
• jasfi 3y ago
  The complexity people think they face with Git can often be overcome with a good UI and/or tutorials.
  • sasham 3y ago
    In part yes, e.g. lots of people like SourceTree. Some of the complexity is inherent though, e.g. local vs remote branches and the various conflicts & errors as a result. Git exists for 18 years, and yet the complexity problem wasn't solved yet. Other tools like SVN were never considered to be so hard to use / easy to screw up.
• aseipp 3y ago
  The Windows Git repository is only 300GB, that's basically childs' play when people are talking about "large repo scalability". Average game developer projects will be multiple terabytes per branch, with a very high number of extremely large files, and very large histories on top of it. Git actually still does handle large files very poorly, not only extremely large repos in aggregate. The problem with large Git repositories is nowhere near solved, I assure you.
  • laeri 3y ago
    This includes assets right or some kind of prebuilt data in custom formats? Otherwise it would be hard to have this much data in source files.
    • aseipp 3y ago
      Yes, game development studios include their raw art and environment assets directly in source control, just like source code. That's because the source code and the assets for the game must go together and be synchronized. That also includes things like "blueprints" or scripting logic. Doing anything else (keeping assets desynchronized or using a secondary synchronization tool) is often an exercise in madness. You want everyone using one tool; most of the artists won't be nearly as technical and training them in an entirely different set of tools is going to be hard and time consuming (especially if they fuck it up.) But honestly, you can ignore that, because Git doesn't even handle small amounts of binary files very well. Ignore multi-gigabyte textures and meshes; just the data model doesn't really handle binary files well because e.g. packfile deltas are often useless for binaries, meaning you are practically storing an individual copy of every version of a binary file you ever commit. That 10MB PDF is 10MB you can never get rid of. You can throw a directory of PDFs and PSDs at Git and it will begin slowing down as clones get longer, working set repos get bigger, et cetera. The 300GB size of the Windows repository is mostly a red herring, is my point. Compared to most code-only FOSS repos that are small, it's crazy large. That kind of thing is vastly over-represented here, though. Binary files deserve good version control too, at the end of the day.