Wrong assumption: `this does not look like a fresh clone`

[KES777]

this does not look like a fresh clone.
  (expected one remote, origin)

If there is only one remote, this does not mean that clone is not fresh.

[newren]

If there is only one remote, this does not mean that clone is not fresh.

Yes, and clearly from the error message the program didn't think there was only one remote, so the rest of your statement isn't relevant. Could you clarify how many remotes you have, from e.g. git remote output?

[KES777]

git remote -v
office  office-repo:office/bot (fetch)
office  office-repo:office/bot (push)

But I added only one remote:

$ git init
$ git remote add office office-repo:office/bot
$ git fetch
$ git checkout dev
$ git filter-repo ...

And here I get error about not fresh clone.

[newren]

git remote -v
office    office-repo:office/bot (fetch)
office    office-repo:office/bot (push)

But I added only one remote:

$ git init
$ git remote add office office-repo:office/bot
$ git fetch
$ git checkout dev
$ git filter-repo ...

And here I get error about not fresh clone.

Ah, yeah, this is totally expected behavior. See https://htmlpreview.github.io/?https://github.com/newren/git-filter-repo/blob/docs/html/git-filter-repo.html#FRESHCLONE . Note that the original statement, this does not look like a fresh clone was not this is not a fresh clone.

[KES777]

Nope, I do not expect this warning if repository is a fresh clone. For example:

1

git clone https://github.com/newren/git-filter-repo
cd git-filter-repo
git filter-repo --path=release/

No warning. Expected.

2

git clone -o office https://github.com/newren/git-filter-repo
cd git-filter-repo
git filter-repo --path=release/

Warning. Not Expected. But repository is a fresh clone.

The better way to check backup copy is fetch before filtering and try to find remote label on first commit:

*   d4f43bc (HEAD -> main, office/main) XXXXXX

So we know that current state has a copy somewhere.

[KES777]

Another way to make sure a backup exists is to backup current branch:

git branch backup
git filter-repo

filter-repo could start new unrelated history and if something went wrong user always could switch back to backup branch.

[me-and]

Another way to make sure a backup exists is to backup current branch:

git branch backup
git filter-repo

filter-repo could start new unrelated history and if something went wrong user always could switch back to backup branch.

I think you have misunderstood some of the problems that filter-repo is trying to solve. One of the key use cases for filter-repo is to remove, thoroughly and completely, files that are not wanted in a repository. The Git internals for storing files don't make a distinction between a file that's in one branch or another. That means that if a file is still accessible from a backup branch after filter-repo has run, the file is still present in the repository and filter-repo isn't useful for that use case.

That is, if I commit secretfile to a repository, I might then use filter-repo to remove secretfile from my main branch. If secretfile is still present in that repository in a backup branch, then when I push that repository to GitHub or elsewhere, the contents of secretfile may be pushed to GitHub even if I didn't push the backup branch. That's part of how Git's internal storage systems work.

The documentation @newren has linked to explains the current logic for checking if a repository is a fresh clone, and why there are both false positives and false negatives. You've found a false positive. That might be surprising to you, but – per that documentation – it's an unavoidable limitation of the tool, not a bug that needs fixing.