git-filter-repo | Quickly rewrite git repository history | Search Engine library

When I installed git-filter-repo on Windows earlier this year, the following steps worked for me:

1. Download and install Python for Windows. Confirm python was added to your path and that you can run either the command python or python3 from your Git command line. (I recommend Git Bash.) In my case, my executable name is python.
2. Clone the git-filter-repo repo from GitHub.
3. Run the command git --exec-path to see your Git exe directory.
4. From the git-filter-repo repo's root directory, copy the file git-filter-repo (about 160KB) into your Git exe directory.
5. In your command line where you use Git, type the command git filter-repo. If it works, you should get the message "No arguments specified."
6. If you get no message or an error message similar to "/usr/bin/env: ‘python3’: No such file or directory", then edit the file git-filter-repo that you copied into your Git exe directory in step #4, and change the first line from "python3" to "python".

Now be amazed at how fast and awesome git-filter-repo is.

Since git filter-repo will recreate the exact same commits if you run it twice on the exact same history (you confirmed it by testing), you can simply use git merge to integrate the new commits, which will appear as descendants of the previous extracted commit.

Thanks to @phd's help, I was able to figure out a working solution:

What is probably the "real" answer is git-lfs like the error message suggests, which github does have support for, but it costs money when over 2GB. If your not in a position that that is available I found this post about how to work around the 100mb file size limit which some have to do with compression which would work well with .fbx files (becuase they are plain text and that compresses well)

Extra note that you left some information in the question that you might potentially want to remove (like your email)

Use git filter-branch for what it's good for, use git filter-repo for what it's better for. I doubt it's possible to make filter-repo do what you're after at all, or at any rate not nearly so well.

I recommend simply ignoring most of the criticisms leveled at git filter-branch, particularly the ones in the filter-repo readme, as regrettably overstated. Put export FILTER_BRANCH_SQUELCH_WARNING=1 in ~/.bashrc and be done with it.

First, do a git config -l --show-scope --show-origin in your repository: that way, you will be sure to see what is a local config, which overrides a global config.

Second, you can use git filter-repo to change the user.name/email of your commits in repoB: yo will then need to git push --force it (which is not a big issue if you are alone working on that new repository).

Why does git-filter-repo remove my remote?

The documentation explains their reasoning, in the section titled INTERNALS:

1. We don’t want users accidentally pushing back to the original repo, as discussed in DISCUSSION. It also reminds users that since history has been rewritten, this repo is no longer compatible with the original. Finally, another minor benefit is this allows users to push with the --mirror option to their new home without accidentally sending remote tracking branches.

And how can I rewrite remote's history using git-filter-repo like I'm able to with git filter-branch?

Just use git remote add to put origin back, or—since step 3 in the command sequence is git remote rm origin—just rename origin to some other name first. If you do that, though, note step 2.

You said:

Adding back the remote manually puts me down a rabbit hole of other settings be invalid.

You'll need to go into more detail here, obviously.

What is wrong ...

There are two things you must not do in a tree filter, in git filter-branch, in general:

1. change the working directory;
2. use Git commands.

This is not necessarily an exclusive list, and, luckily, there are some ways around these two.

and how to fix this problem?

The limitation on changing directories is actually specific to shell commands run in the top level shell (filter-branch evals your filter here). Since you're firing up a completely separate process, python, that allows you to change the working directory. But it's worth mentioning the issue, since an attempt to optimize your filter might result in running into it.

The limitation on using Git commands is because a tree filter is specifically aimed at letting you use non-Git commands to rework the contents of each commit. Using git filter-branch simply to examine the contents of each commit wasn't the intent here.

Fortunately, there is a simple workaround for running git init like this: you just need to remove the environment variable GIT_DIR from the environment when you invoke Git. If you invoke other Git commands there may be more environment variables you must unset.

Overall, though, it's not clear why you're trying to use git filter-branch for this. If you want to get a list of commits, the correct tool is usually git rev-list. If you want to get files from those commits, things get more complex, but filter-branch is still probably not the right tool.

Eventually find the problem root cause.

It seems that running git filter-branch in a network directory is not that robust. I copied the files to the local machine and could successfully run git filter-branch command.