41–50 of 440 posts
Also agreed git is terrible right now for version-controlling workflows in AI (I have a fairly large .gitignore file with S3-hosted things ever for my NextJS + FastAPI apps - pain in the butt
I'd like to hear about how this happened. No one in the team heard of reflog?
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…
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.
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.
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…
> 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?
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
Nice. I make music and use git for my files, but often hit the usual space limitations and I hate dealing with git-lfs. I think there's a big use case for Diversion and music/video production.
May I ask, how you use Git for your music? Since binary diffs are not really a thing, the main benefit I could imagine is simply having revisions of your files with you having to create folders or having files named "track01_test_final2.flac"
> In our previous startup, a data scientist accidentally destroyed a month’s work of his team by using the wrong Git command. While git is indeed a usability clusterbomb and there is massive space to improve, the problem above sounds like a devops failure. Git gives you all the tools to prevent such a disaster, all you have to do not give the root password of your CI server to any data scientist. On the topic of your…
I also always wonder in cases like this if the person just didn’t know about reflog. You _really_ have to try to fuck up hard enough that everything is gone, it just might require even more arcane commands than what got you into a mess.
> You _really_ have to try to fuck up hard enough that everything is gone
...is still true when using git-lfs, which seems common when using large data sets.
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…
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 de…
Using git with bash is the best way to use git (:
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?
Should a chain saw come with the ability to start the engine disabled by default?