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.
Edit: updated in the top text now!
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.
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.
Doesn't say a lot for git's usability.
Git is great in that it is flexible and powerful. But that power leaves some tools open to people who don’t know what they are doing… that’s the trade off.
(Now something that better handles non-code assets and large data files, I’d be much more willing to listen to that pitch.)
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 "git alternative" would be all the worse if it didn't provide it, IMO.
Two is that if the concern is git's usability - i.e. the "problem" here is that it's too "easy" for users to do destructive actions accidentally - well, there are ways to solve that other than to reinvent all of git. There are plenty of alternative git UIs already, and an alternative UI is a great way to be "wire compatible" for existing users but still help protect those novice users from footguns.
Though I'll say that "--force" isn't necessarily a "scary-sounding" option name unless you're used to Unix CLI naming conventions.
Further, the warnings git gives you about this are virtually inscrutable if you don't already understand what's happening.
A good interface to "blowing away history" would give you a brief summary of what will actually be gone, e.g.:
"If you go ahead with this overwrite, the following changes will be completely removed from the repo:
a3bf45: Fix bug in arg parsing 22ec04: Add data from 2024-01-17 scraper run ...
Are you SURE you want to completely destroy those commits? (Y/n)"
and if user says "Y", output should log all removed commits and also say:
"These commits can still be recovered until <date>. If you realize you want these back before then, run the following:
<command to restore commits>"
Generally, I think it's a mistake to put UI improvements in a secondary tool.
If there are issues that need fixing, get those changes in the canonical project, because layered patches on top will always be short of maintainers and behind the main project.
While there is a lot of user interfaces that could be improved, I believe the above have empirically been shown to be inferior to the alternative "re-run this command but add scary option to proceed".
Users habitually answer "Y" to questions like the above all the time. And certainly after a few times it becomes routine for anyone. But having to re-enter the command and type some a whole word like "overwrite", "force" or "i-know-what-im-doing" is a whole other roadblock. The example is especially ill-chosen to have Y as the default option.
Any operation in git that destroys so many commits will include a list of commits that is destroyed, similar to what is suggested here, and trying to push the resulting repository will say exactly how many commits will be removed, and require rerun with force option (together with the necessary privileges). So reality is already not far from what you suggest, but with more fail safes.
The clear warning about what commits will be lost is not at all how I remember force-push working.
That said, I usually use magit in emacs for git and understand the force options well, so I haven't actually looked at the standard push failure warning in years. Maybe I'm remembering wrong, or perhaps it's been improved in recent versions.
Multiple individuals with similar problems would tend to imply systematic inadequate training. Or the enterprise concerned adopting an inappropriately complex system for its intended userbase.
At least with git, every developer has a copy of the full history so full data loss is impossible really. What happens if this company folds? You're left with some proprietary repo that you suddenly have to workout how to self host.
It just doesn't make sense when compared to just learning git which is definitely the most fruitful thing a developer could learn at the start of their career.
I wonder how Diversion handles operations that possibly delete data. Whats their solution?
Actually those commits that you considered lost, were still stored on everyone's personal computer in your team. You just didn't know how to use `git reflog` to find them.
I'm trying to imagine how to generalize this to other products. I think if I state the competing product has negative feature X, but also intentionally get some details confidently incorrect or deliberately feign incompetence, you get a group of people confirming X.
Git doesn't give you access to the server side reflog either. So it's of not much use if you don't control the server.
As for losing data with Git, the easiest way to accomplish that is with data that hasn't been committed yet, a simple `git checkout` or `git reset --hard` can wipe out all your changes and even reflog won't keep record of that.
Also Git has pretty awful behavior losing changes when one doesn't press "Save" in their IDE. Bad, bad Git.
It's what I end up doing manually anyway but why make a system where the default behavior is destructive and I have to remember every.
Not only is it quite careful about not losing data, someone actually took the time to make it spit out messages that not only describes what just happened, but also gives suggestions of what to do next depending on how the user wants to proceed. That adds a level of discoverability that is usually associated with dialog based guis. The quality of these messages can sometimes be surprisingly good, far from the Clippy-level helpfulness you sometimes see.
There are a few exceptions to the principle of not losing local changes, where you explicitly restore an old version of a file for example. But saying the default behaviour is destructive really gives a false impression.
But yes, you are absolutely right that a system to recover unsaved work is a good thing, but I would argue that it belongs at the editor level, not in a version control system. A user could have a number of files open that have local changes. The editor has a much better idea in which order changes were made, and which changes hasn't even been committed to disk yet.
Using their desktop apps, Pages, Keynote, Numbers, TextEdit, Preview, I never hit "Save". I just close the apps. When I come back, the windows reopen right where I left off.
I wish emacs did this. I honestly don't know what it would be like for a code editor to be "constantly saving". I guess I would adapt, but there are times when I do all sorts of changes and go "Ah, this isn't right" and just kill the buffer. The ultimate undo.
But there's a great feeling, to me, when I go to close the app (or shutdown the computer) and it just closes. No prompts, no warnings, just saves its state, shuts down, and comes back later. And with the ever popular "naming things" issue of computers, I have a bunch of just "Untitled" windows. They're there when I open the app, and that's all I need to know.
The nag factor and cognitive load reduction of that is just unmatched. "Just deal with it, I'll come back later, maybe, and clean it up". One less thing.
Neither is it the fault of your version control system, or any other system really, if you cannot access your server and are without backups.
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.
What you describe would be 1 Minute of work and maybe 10 clicks with a very low probability of shooting yourself in the foot in Tower.