51–60 of 440 posts
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.
Earlier quoted context omitted.
True! They didn't actually have a root pwd to anything, the repo was hosted on BitBucket which didn't have a branch protection feature back then. Non-coder users are actually an important use case for Diversion (like in game development where many/most users are artists).
And nobody on the team had a reasonably fresh checkout of the repo on their local machine? To put it bluntly, this story does not sound credible. It's also one of the first things you say in the pitch, which taints everything you write later. I would suggest focusing on what you do well, not in making up stories about data loss with what you perceive as the competition. (It's especially odd when Git isn't the obvious…
Can someone explain how is this possible? More importantly was there any git branching strategy and permissions?
Earlier quoted context omitted.
> 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?
--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.
Well, you just mentioned `--force`. It is unsafe by default. Git has a couple of flags to make it safer (`--force-with-lease`, `--force-if-includes`) but those aren't the default.
Earlier 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.
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
> In our previous startup, a data scientist accidentally destroyed a month’s work of his team by using the wrong Git command. Can someone explain how is this possible? More importantly was there any git branching strategy and permissions?
Earlier quoted context omitted.
Should a chain saw come with the ability to start the engine disabled by default?
Yes. That is a great idea. You could do something like a tab that you have to remove that tells you about chainsaw safety.
If stackoverflow told them to break off the chainsaw safety tab there is no chance it would have been read first.
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 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…
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.
I would start by talking about what is great about Diversion -- what it lets you do that you couldn't before.
Since you mention gaming and perforce I looked in vain to see if it supports binaries (a major limitation of git -- just simply not in its design space). "Binaries" can actually mean for some people compiled code -- not for me but I understand why people do it -- as well as images, data files, Word files etc.
Sounds like the second is scaling but you don't say what you mean by that. Git scales pretty well until either the repo & its history gets enormous or when there are a lot of people making simultaneous changes.
The realtime collab integrated with a version control mentality could be interesting -- a major problem with google docs is the lack of useful version control (even Word is better).
And why cloud native?
Once you've done that you need only briefly mention "why not just use git instead?"