191–200 of 440 posts
Having worked with SVN a decade ago and Perforce more recently: that part of the market is waiting to be disrupted. I'm a little unsure whether it was actual technical reasons (vs cultural) that kept git out of those use cases. Many devs were working with git locally and using git-svn or git-p4 to interact with the local repo. Best of luck!
> The biggest drawback of Git is its limited scalability - both in repository and file sizes, and the number of concurrent users. How did you come to the conclusion Git isn't scalable in the number of users? There is no limit in the number of users with Git. There may be limits in the number of interaction between those users, i.e. pull/merge requests, clones, fetches etc. But they are mostly limited by humans. A cen…
The number of concurrent merges is definitely a problem. With a few hundred developers committing to the same repo all day, it becomes a chore to make sure that their commits can still be put on top of each other, and that one out-of-sync commit is not holding back a bunch of others which depend on it. This all is solvable, both through discipline and tools. But if a VCS has a built-in capability to alleviate this, i…
Having hundreds of committers merging into one branch is problematic. Perhaps splitting the repository into smaller parts does have its advantages. Monorepos often have the architectural split of the software while throwing away the advantages of the split at the vcs level. But there is also other large software, developed by hundreds of people, that cannot meaningfully split into separate git repositories without messing about versioning and releasing. The Linux kernel is such a system. They use a loose network of repositories -- mostly a hierarchy -- to pre-aggregate merges. Git is well equipped to handle different approaches -- separation of mechanism and policy.
I am looking forward to learn how a central but cloud-native VCS will improve on that.
Earlier quoted context omitted.
Or, git is both very complex and very useful, and a large portion of its users have a poor understanding of git but enough for it to be a useful tool. If you want to do source control (which you do), then you’re investing time into learning git and/or fixing git, or maybe using a project like this.
You literally just said what GP said in different words, but prefaced it with "Or" as if it's a disagreement. What you said boils down to "inadequate training".
Earlier quoted context omitted.
--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.
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')
Being 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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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
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.
The fact that they don't seem to fully understand working of Git (not on the level of Git developers, just the level of Git administrators/users) does not inspire trust in their competence to create a Git alternative.
Earlier quoted context omitted.
For your information you can use the reflog command to find the previous head commit and restore your branch. It takes 10 minutes and then you learn to disable force pushing on the main branch.
I find it funny how many comments in this angry rebuttal section actually endorse a Git replacement.
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…
Taking a decentralized application like Git back to centralization is a step in the wrong direction, it's exactly why Git was created.