Feature Requests: Don't remove remotes if branch is not tracked

[kmcclellan]

Like the many commenting in #46, I too find it frustrating and a bit patronizing that this tool removes my remotes. I want to point out that there are usages of filter-repo that don't rewrite history. Most commonly, I create a new branch from some feature branch, modify its commits, and then push it as a v2 version which gets merged instead of the original. History is kept intact.

Of course, I still have trouble seeing the value of this protection since Git already protects you from rewriting history (unless you force-push). Perhaps if it would be a compromise to only apply this protection if your branch is tracking a remote?

[newren]

Most commonly, I create a new branch from some feature branch, modify its commits, and then push it as a v2 version which gets merged instead of the original. History is kept intact.

So, you're basically doing a partial history rewrite. Is there a reason you're not passing --partial?

Of course, I still have trouble seeing the value of this protection since Git already protects you from rewriting history (unless you force-push).

Sadly, that protection merely gives the illusion of safety. Users will see it and say, "Well, duh, I wanted to rewrite this history." What they don't understand is what their colleagues will do. Their colleagues will then merge their (already cloned) old history with the new history that is force pushed, and push back the merged result (and these colleagues won't even need to force push). That recontaminates the repository with the sensitive or large data that had been removed and now makes the cleanup a lot harder.

What is needed is a way to prevent colleagues from re-pushing the old commits.

This may arise because there are cases when people do really want to force push and overwrite everything, and they are being careful to replace the old history everywhere with the new AND putting some mechanism in place to prevent everyone else from pushing the old history back to the same repo (or perhaps they are the only user and have no colleagues to worry about). However, they summarize what they do or did on a blog post, implicitly assuming everyone else is being careful and are as clueful as them, but resulting in newbies seeing the advice, "After running $FILTERING_TOOL just force push". Folks new to history rewriting do a few google searches, see that advice, and blindly do it, then have a colleague push something based on the old history (possibly merged with the new), and get themselves into a royal mess that is really hard to dig out of.

Perhaps if it would be a compromise to only apply this protection if your branch is tracking a remote?

I appreciate the attempt to find a compromise, but I don't think this one makes much sense. filter-repo, by default, is for rewriting the whole repository not a single branch. If you're going to rewrite a single branch, you already have to specify options of some kind (likely --refs which will imply --partial already and make this moot, but even if not the user can always add that flag to the others they are using). And even if you expanded this idea to check all (relevant?) branches, that doesn't address the cases where the things being rewritten aren't a branch but are a tag or some other ref.

Now, if all the major forges had a way to prevent colleagues from re-pushing old commits, I could revisit this default. Sadly, only one does (Gerrit) and I worry it's becoming harder to consider it "major".

[Kodiologist]

Their colleagues will then merge their (already cloned) old history with the new history that is force pushed, and push back the merged result (and these colleagues won't even need to force push).

If people don't understand how rewriting history works in Git—and how to manage it as a group all pushing to the same repository—then they shouldn't rewrite history. This goes for all rewriting tools, including built-in features like git rebase, which don't delete your remotes. Deleting remotes that the user didn't ask to be deleted, especially when the user is rewriting commits that never got pushed in the first place, helps nobody.

I suspect that as long as #46 stays closed and locked to comments, you're going to keep getting new issues complaining about essentially the same thing.

[newren]

Their colleagues will then merge their (already cloned) old history with the new history that is force pushed, and push back the merged result (and these colleagues won't even need to force push).

If people don't understand how rewriting history works in Git—and how to manage it as a group all pushing to the same repository—then they shouldn't rewrite history. This goes for all rewriting tools, including built-in features like git rebase, which don't delete your remotes.

I understand the sentiment, but I think it's totally divorced from reality unfortunately.

Deleting remotes that the user didn't ask to be deleted, especially when the user is rewriting commits that never got pushed in the first place, helps nobody.

And how exactly is filter-repo to know that your commits never got pushed? By reading your mind? By connecting to all other git repositories in existence to determine if any of them contain your commits?

I suspect that as long as #46 stays closed and locked to comments, you're going to keep getting new issues complaining about essentially the same thing.

Regardless of what I do, there will be new issues with folks complaining. If I remove the remotes, people will complain about that, even if it's utterly trivial for them to workaround and takes like 30 seconds. If I don't remove the remotes, people will complain about how after they force pushed their history, their colleagues then did a git pull && git push and royally screws everything up and it'll take them weeks to go and fix. I understand that people from the former group think they are far more important and the 30 seconds it takes them to put the remote back totally outweighs the weeks of effort people on the other side will be forced to go through.

Either way, I'm going to get complaints, and it's far easier to deal with the complaints from the first group.