Resotre after --force

[mihalt]

Hi! I've run git filter-repo --force --commit-callback 'commit.committer_date = commit.author_date'. And I see now that reflog was cleared the same as all remote branches. Do you have recommendations how can I restore this quickly?

[newren]

Sure, go restore from your backups. You took some backups before running a command whose manual starts out warning you that you are running a destructive command, and when running with the --force flag which is explicitly documented to ...include immediate pruning of reflogs..., right?

[mihalt]

Sure, go restore from your backups. You took some backups before running a command whose manual starts out warning you that you are running a destructive command, and when running with the --force flag which is explicitly documented to ...include immediate pruning of reflogs..., right?

I would not ask you the question if I did a backup :-) Fortunately I restored .git folder from my ssd history. But I would like to know, is it possible to restore without it too.

[newren]

Sure, go restore from your backups. You took some backups before running a command whose manual starts out warning you that you are running a destructive command, and when running with the --force flag which is explicitly documented to ...include immediate pruning of reflogs..., right?

I would not ask you the question if I did a backup :-) Fortunately I restored .git folder from my ssd history. But I would like to know, is it possible to restore without it too.

No there is not, and there never will be:

• Providing an alternate method to restore would require storing both the original history and the new history, meaning that those who are trying to shrink their repository size instead see it grow and have to figure out extra steps to expunge the old history to see the actual size savings. History showed with other tool that this was frustrating and difficult to figure out for many users.
• Providing an alternate method to restore would mean that users who are trying to purge sensitive data from their repository still find the sensitive data after the rewrite because it hasn't actually been purged. In order to actually purge it, they have to take extra steps, which again has made things difficult for users in the past.
• Providing an alternate method to restore would also mean trying to figure out what should be backed up and how. The obvious choices used by previous tools only actually provided partial backups (reflogs would be ignored for example, as would uncommitted changes whether staged or not). The only reasonable full backup mechanism is making a separate clone, which is both expensive and something the user can and should understand how to do on their own.
• Providing an alternate method to restore would also mean providing documentation on how to restore. Past methods by other tools in the history rewriting space suggested that it was rather difficult for users to figure out. Difficult enough, in fact, that users simply didn't ever use them. They instead made a separate clone before rewriting history and if they didn't like the rewrite, then they just blew it away and made a new clone to work with. Since that was observed to be the easy restoration method, I simply enforced it with this tool, requiring users who look like they might not be operating on a fresh clone to use the --force flag.

But more than all that, if there were an alternate method to restore, why would you have needed to specify the --force flag? Doesn't its existence (and the wording of its documentation) make it pretty clear on its own that there isn't going to be a way to restore?