[flagged]
Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative
151–160 of 440 posts
Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative
#152I 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 on Git in your pitch. >> it was built for a very different world in 2005 (slow networks, much smaller projects, no cloud) 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. Mu…
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.
I configured my github to only allow commits with an anonymised email address. Time passed and I used another machine on which I had already opened that repo before. I pulled my recent work successfully, wrote stuff and then committed and pushed.
Github rejected my commit as I had the wrong email address. I then had to try and work out how I delete a commit but keep all my changes so I could commit it all again but with the correct email address.
I'm not sure exactly what I did but in my ham-fisted experimentation I deleted the commit and restored my local copy back to the way it was before my commit, losing all my work that day.
Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative
#153Earlier quoted context omitted.
And the tool made a screwup that hard not only possible, but very difficult for the victims to recover from. Doesn't say a lot for git's usability.
A couple of thoughts about this: One is that the possibility of overwriting history / etc is a really powerful and useful feature, but one that should only be used with some consideration, hence being gated behind the scary '--force'. The fact that git provides one the ability to discard and overwrite commits for a ref shouldn't be an endorsement of doing so freely. I'm glad git has this capability though and any "gi…
It doesn’t overwrite the commute though. It inserts new ones and resets the branch pointer … doesn’t seem like you’d need a whole new tool to mitigate this - just an automatically generated tag or something when you —force-push - would be easy to do if there was demand for it …
Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative
#1541. git is not hard if you learn it 2. I regularly see people storing multiple gigabyte files in git.. I don't understand your issue with large files. 3. cloud native? why? part of the point of git is to have a repo decentralized away from centralized clouds onto dev's machines, if your data scientist broke git then that means your main branch configuration is off, no one else had that cloned onto their machines, and…
I don't think you understand the scale of large creative projects like games. The current (only medium sized) Unreal Engine project I'm working on has about 300k files in the head alone, and a fresh sync for the stuff only required to build/cook the game is about 350GB. If you add the raw content from things like Maya, substance Painter, brush, etc, it is well in excess of 1TB.
Vanilla git just does not scale to this. Microsoft git and Scalar get much closer, but require a bunch more setup and are a giant foot gun if someone tries to use the repo with vanilla git. Add to that the lack of permissions control and remote management, and it is just not a good fit for an industry where say 75% of the contributors are non technical.
Git is a fantastic tool and works for the vast majority of software projects, but there are non trivial amount of projects out there that it just doesn't suit.
Perforce, as horrible as it is, is the game and VFX industry default for a reason - think of it this way, given how notoriously cost driven and penny pinching games companies are, don't you think they'd be using a free/cheaper alternative in hosted Git if they could? But they don't. This is why.
Good luck to the Diversion team, more competition in this part of the market can only be a good thing.
Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative
#155Earlier quoted context omitted.
I think you just sold their pitch with this comment... I, like many many people here, have done quite a bit of product design. What do you call it when a bunch of people use your product, and it breaks for several of them? That generally indicates your product is weak, or has a very rough UI.
The pitch simply wasn’t true. Data was not destroyed and was restored hours later.
It's a pitch. The story has obviously been embellished and polished and condensed, ready public consumption. Being pedantic against it is not productive.
Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative
#156Earlier quoted context omitted.
Just curious, why do you want that to be version controlled?
Because I might realize later I made a mistake, or I might want to view history. I’d I never cared about historical state and mistakes, I wouldn’t need version control at all :)
You could delete the branches locally while archiving them to any another clone of the repo.
Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative
#1571. git is not hard if you learn it 2. I regularly see people storing multiple gigabyte files in git.. I don't understand your issue with large files. 3. cloud native? why? part of the point of git is to have a repo decentralized away from centralized clouds onto dev's machines, if your data scientist broke git then that means your main branch configuration is off, no one else had that cloned onto their machines, and…
> 1. git is not hard if you learn it
I basically agree. People want to just pick up a tool like git and have it just work without investing much time in it. I can understand this desire in a complex world with many tools, but something as powerful as git is really worth learning. I swear if people spent like 1 hour a day for a week in actual git training, and then did refreshers 1 hour a month as they were using it on a team, this would be less of a problem.
You don't need to know every feature, but knowing how to rebase, use the reflog, use the pickaxe, understand the concept/value of bisect and how to look up how to use it, etc. is so valuable.
The other day a professional developer told me he didn't know you could write more than 1 line in a git commit message. WTF.
Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative
#158Being deceptive about Git's shortcomings is going to raise eyebrows with anyone seriously evaluating your solution, which is already going to raise eyebrows because it's not free software. Most studios will try to avoid locking themselves into another expensive, annoying VCS that they have no control over. There's good attempts at FOSS p4 replacements now, you need to do better if you want to stand out.
> Being deceptive about Git's shortcomings Are they being deceptive? I'm not sure I see it.
Not deceptive but I would say they're being hand wavy.
Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative
#159Earlier quoted context omitted.
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.
I configured my github to only allow commits with an anonymised email address. Time passed and I used another machine on which I had already opened that repo before. I pulled my recent work successfully, wrote stuff and then committed and pushed. Github rejected my commit as I had the wrong email address. I then had to try and work out how I delete a commit but keep all my changes so I could commit it all again but w…
If you had already committed, `git reflog` should have still found your changes (even after you deleted the commit and restored the local working tree) unless you deleted and re-cloned the repository.
Re: Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative
#160I 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 on Git in your pitch. >> it was built for a very different world in 2005 (slow networks, much smaller projects, no cloud) 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. Mu…
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.
I agree. It's quite hard to actually destroy data in git. Even with the so called "destructive" commands, walking through the reflogs can usually restore work that was accidentally deleted or whatever.