filter-repo removes my remotes about git-filter-repo HOT 7 CLOSED

It's not good design.

1. git remote rm exists for remove remote tracking branch, not for prevent git push. I don't want to use a function to other purpose.
2. It is documented, but only documented. Not all users see the all of document before use the command. And logs does not show that command removes remote tracking branch, it confuses users. I want to see the message like Remote tracking branch has removed to prevent some accidents.
3. No way to keep remote repository. If removed suddenly, need some steps to recover (failed to push, check remote URL, git remote add <URL>). --refs and --partial keeps remote, but it seems side effect. Can I use like --keep-remote at my own risk?

from git-filter-repo.

Yes, absolutely, filter-repo defaults to rewriting the whole repository and as such it creates history incompatible with the original. There are lots of things that can go wrong with pushing a rewritten history back up to the original location, something that other tools did not discuss or warn about in detail and which will trip up many people. Removing the origin remote helps avoid these errors; it is encouragement for folks to stop and read the docs to make sure they are prepared and understand the ramifications (and take appropriate preventative steps) before they do something that may bite them. (They can still push to the remote by just setting it back up, can just re-fetch, etc., so it's easy to circumvent, but I want them to at least notice something is different).

This is all documented in the following places:

• Step 4 of Discussion in the manual
• Steps 2 & 3 of Internals -- How filter-repo works
• And in the documentation of both the --partial and --refs options.

As noted in the documentation for --refs and --partial, those options are designed to only make changes on a piece of history while intending to keep the rest of history as-is. As such, those options disable the steps to map the remote tracking branches to normal branches and disable the removing of the origin remote. Looks like you already noticed that you forgot to include --refs in the last step.

from git-filter-repo.

1. git remote rm exists for remove remote tracking branch, not for prevent git push. I don't want to use a function to other purpose.

You have a few errors here: (1) Removing the remote tracking branches is a side-effect. The purpose of git remote rm is to remove the remote. (2) Removing the remote tracking branches is part of the point of me using this command; your local branches no longer track the remote as they've been rewritten. (3) Your assumption that the goal was to prevent git push is mistaken, and it'd be a horrible failure if that was the goal since it is so incredibly easy to push anyway. The goal is just to help users double check that it's really what they want to do.

2. It is documented, but only documented. Not all users see the all of document before use the command. And logs does not show that command removes remote tracking branch, it confuses users. I want to see the message like Remote tracking branch has removed to prevent some accidents.

That's fair; it looks like I currently only show a message in this case in debug mode; we could make those messages always show instead.

3. No way to keep remote repository. If removed suddenly, need some steps to recover (failed to push, check remote URL, git remote add <URL>). --refs and --partial keeps remote, but it seems side effect. Can I use like --keep-remote at my own risk?

It's trivial to restore, though: git remote add origin <URL> && git fetch origin.

It's not good design.

When there are trade-offs involved, merely stating known drawbacks to one approach is inadequate for arguing for a different trade-off. You also need to discuss the issues on the other side. In particular, my experience with history rewriting is that many users do it, then end up pulling (and remerging) with the un-rewritten history, and then end up with a huge mess that'd take hours to recover from for a simple repository, days for even small to medium repositories, and weeks or longer on big repositories. In fact, in some, it might just be that they don't get to recover because they only had one chance to do a flag day cleanup but ended up with a flag day muddying that made things worse. git is distributed, and is designed to work with disparate repositories and diverging histories, so it's really easy to go down this mistaken path; the steps are nothing more than "git pull && git push". This safety check has saved many people from huge amounts of pain.

In contrast, while having the origin remote removed is annoying to those that really do want to force push over their history, it's a minor annoyance at most. All they have to do to recover is git remote add origin <URL> and then continue on with their work.

So, in the end, I guess I can agree with you that my decision was not good design. It was great design, and one of the things I'm most happy about choosing when coming up with filter-repo.

from git-filter-repo.

I think I am missing --refs $BRANCH in that last command, maybe that has something to do with it.

It should still not lose the remotes though

from git-filter-repo.

My current workaround to this issue is to use github remote rename.

from git-filter-repo.

It would be nice if there was a warning like "hey, you really should read the docs [here] before you do this, are you ready to commit? Things might go wrong. [y/n]"

I took some advice from StackOverflow, ran a command and now my remote is gone which makes me think I did something VERY WRONG but in fact it's fine, I just didn't know it would remove my remote.

Have you heard of Principle of Least Surprise? This violates that. Removing remotes is a surprise with no warning in front of it.

in the end, I guess I can agree with you that my decision was not good design. It was great design

This sounds so smug.

You could also help the user by emitting "hey here's your remotes, you'll need to add them when this is done..."

from git-filter-repo.

It would be nice if there was a warning like "hey, you really should read the docs [here] before you do this, are you ready to commit? Things might go wrong. [y/n]"

The premise behind your suggestion, that git-filter-repo undertakes dangerous actions without warning, is incorrect. First of all, if git filter-repo detects the repository is not a fresh clone, it'll abort unless the user has specified --force. The fact that you got to the point of it removing remotes either suggests you started with a fresh clone (in which case you lose nothing if remotes are removed since you can simply clone again), or that you explicitly overrode safety checks with --force (in which case, you told it to go ahead anyway). Either of those cases make little sense in combination with your suggestion.

But that's not all. The removal of remotes was added precisely as a way to warn users that things might go wrong if they attempt to use the results in common but dangerous ways. git filter-repo has no control of what you decide to do with the repository after it is done running. And, in particular, I've seen users take repository rewrites done with other tools and merge the rewritten history with the original and end up with a MUCH bigger mess than they started with. That kind of thing takes weeks to recover from. Since the rewritten history is incompatible with the original history, and merging the two together tends to be highly problematic, providing some mechanism which requires the user to take extra steps before they might make such a mistake is thus warranted. Taking a step which users can override with a simple command when they understand the consequences seems like a good choice. And, in fact, that is exactly what removing the remotes does.

Also, have you heard of the principle of alert fatigue? When you always (or frequently) display warnings, users just start ignoring them, and users get exceptionally annoyed. Your suggestion to always show such a warning definitely runs afoul of that principle...and it does nothing to help with the potentially even bigger mistakes users might make after the tool is done running to boot. Even if I did add such a warning, users would complain and ask for a flag for the message to be bypassed (and possibly make --force imply such a flag). And all future answers on Stack Overflow would just use that new flag (and likely many of the existing ones would be edited to add that flag), and then users who just blindly follow Stack Overflow questions would just copy one of those suggestions and then come here and complain that no warning was shown. So, the warning's only effect would be to annoy users.

Have you heard of Principle of Least Surprise? This violates that. Removing remotes is a surprise with no warning in front of it.

Of course I've heard of it. In fact, I designed this feature with that principle in mind, and alluded to it above. Now, with the use of this tool, it turns out it's impossible to avoid a Principle of Least Surprise violation for all users: I can either allow users to run into an extremely nasty surprise when they accidentally merge rewritten history with original history, taking them weeks to recover from; or I can give other users an entirely innocuous surprise when they really do want to force push their history over the original, taking them 15 seconds to carry on. You seem to be suggesting that weeks of recovery time for others trumps your 15 seconds to re-add the remote?

You could also help the user by emitting "hey here's your remotes, you'll need to add them when this is done..."

That would leave users to believe that pushing back to the remote is the right thing to do, and cause users to blindly re-add them. That's exactly the problem I want to avoid. People should read the documentation before re-adding them so they are aware of the pitfalls. Anyone who has read the documentation would likely understand why I think this is a bad suggestion.

This sounds so smug.

Two things:

(1) Your entire comment sounds kind of petty, to me. I don't see how saving you from 15 seconds of work (to re-add the remotes) can possibly be more important than saving others from royally screwing up their history and requiring weeks worth of effort to recover. I've got enough cases where people messed things up (e.g. #291 (comment) and #461 (comment)). Your suggestion would add a bunch more. I much prefer getting the "Life is so unfair that I have to run git remote add origin ${ORIGINAL_URL}, that takes so much time" messages than the "my history is wrecked!" messages.

(2) With the benefit of hindsight, I think I can say that my original response wasn't what I'd use today. Allow me to modify it:

My decision to remove remotes was not good design. It was GREAT design, and one of the things I'm most happy about choosing when coming up with filter-repo.

from git-filter-repo.