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