[JeremyNT]

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 "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.

[NateEag]

That all makes sense and mirrors many of my own thoughts.

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.

[xorcist]

> Are you SURE you want to completely destroy those commits? (Y/n)

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.

[NateEag]

You make a good point about "Y/n" being more dangerous than refusing and requiring an explicit option be passed.

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.

[rusk]

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 …