Fresh clone not recognized as such about git-filter-repo HOT 12 CLOSED

Oh, indeed, that's such a small repo that when you clone, you only get loose objects rather than a pack. The default for transfer.unpackLimit is 100, meaning you need at least 100 objects (combinations of blobs, trees, commits and tags), otherwise you'll run into this issue. I suspect this issue is only going to arise when people are trying to come up with simple testcases for filter-repo. You can work around it with a simple git gc in the repo.

Thanks for the report, but I'm not sure what to do beyond suggesting this workaround to the few folks coming up with small filter-repo testcases. There is nothing official marking something as a "fresh clone", instead I just check about a dozen things that happen to be true (meaning you can manually tweak an existing repo that was created from scratch and never cloned into looking like a fresh clone), but I guess that leaves some corner cases like this.

from git-filter-repo.

nice, but it begs the question if a simple git gc resolves it, can this not be done as part of the first check?

Part of the whole point of the checks is "what level of confidence do I have that this is a fresh clone?" and in particular I'm asking the question because I don't want to do a big history rewrite on anything the user might not have a backup of. If I instead decide to start mucking with the storage to make it look closer to what a fresh clone usually looks like, then I'm simply throwing away a datapoint that might prevent an accidental rewrite. If I'm going that route, I could just dispense with the checks and hope users read the documentation and are always careful to only run on fresh clones.

I don't want to go that route; I put the safety checks there because I want to prevent mistakes. I even once ran git-filter-repo, as I intended to, but within the wrong repo. Were it not for my fresh-clone safety checks, some local changes would have been obliterated. I know it's annoying to have the safety checks fire with a false alarm, but I'd much prefer a rare false alarm than a missed real alarm.

I know false alarms can cause people to ignore the alarms so I'm leaving this open while considering possibilities for tightening the logic. I'm undecided/unsure right now what that might be.

from git-filter-repo.

Would it be possible to add something along the lines of #38 (comment) in the error message? Personally it was not clear to me what a fresh clone meant and how to proceed.

from git-filter-repo.

Indeed, git clone --no-local works even without git gc.

from git-filter-repo.

Just fixed this with commit b1fae48 (filter-repo: relax the definition of freshly packed, 2020-03-21)

from git-filter-repo.

nice, but it begs the question if a simple git gc resolves it, can this not be done as part of the first check?

works for me though, exactly what i needed 🙂

from git-filter-repo.

nice explanation, very clear, ty!

from git-filter-repo.

I came across the same issue on fresh clone of my private repository and wanted to report it but found this closed one.
I use Git for Windows 2.26.2 on Windows 10.
Here are the details:

$ git --version
git version 2.26.2.windows.1

$ git clone /c/gitrepos/cpp fresh_clone
Cloning into 'fresh_clone'...
done.
Updating files: 100% (1890/1890), done.

$ cd fresh_clone

$ git count-objects -v
count: 1460
size: 11210
in-pack: 2740
packs: 6
size-pack: 18703
prune-packable: 92
garbage: 0
size-garbage: 0

$ git filter-repo --mailmap /c/gitrepos/my_mail_map.txt
Aborting: Refusing to overwrite repo history since this does not
look like a fresh clone.
  (expected freshly packed repo)
To override, use --force.

$ git gc
Enumerating objects: 3637, done.
Counting objects: 100% (3637/3637), done.
Delta compression using up to 4 threads
Compressing objects: 100% (2591/2591), done.
Writing objects: 100% (3637/3637), done.
Total 3637 (delta 2058), reused 2011 (delta 999), pack-reused 0

$ git count-objects -v
count: 0
size: 0
in-pack: 3637
packs: 1
size-pack: 22850
prune-packable: 0
garbage: 0
size-garbage: 0

$ git filter-repo --mailmap /c/gitrepos/my_mail_map.txt
Parsed 174 commitsHEAD is now at 55a63cb XXXXXXXXXX
Enumerating objects: 3637, done.
Counting objects: 100% (3637/3637), done.
Delta compression using up to 4 threads
Compressing objects: 100% (1532/1532), done.
Writing objects: 100% (3637/3637), done.
Total 3637 (delta 2058), reused 3569 (delta 2058), pack-reused 0

New history written in 1.11 seconds; now repacking/cleaning...
Repacking your repo and cleaning out old unneeded objects
Completely finished after 2.88 seconds.

If the fresh-clone check cannot be improved, then maybe at least mention "git gc" in the error message to save user's time?

from git-filter-repo.

$ git clone /c/gitrepos/cpp fresh_clone

Yeah, I should probably specify to people that they need to pass --no-local when cloning a repository off the local filesystem. As the git-clone manual states, in that case git "bypasses the normal Git aware transport mechanism" for repositories on the local filesystem and instead does hard-linking/copying in ways that make it look like not-a-fresh-clone.

from git-filter-repo.

@newren Hit the same as @valiko-ua and git clone --no-local made filter-repo work for me too.

Now that I know that git switch, I see it's mentioned under the -f option: if I may, I'd like to suggest adding it to the [FRESHCLONE] section and maybe near the [...] Also, it’s worth noting that there is an important safety mechanism: [...] under [DESCRIPTION] too.

from git-filter-repo.

Good suggestions, @watery, I just pushed commit d87b665 (git-filter-repo.txt: connect --no-local and fresh clones more thoroughly, 2020-06-01) to do so.

from git-filter-repo.

@newren Cool, thanks!

from git-filter-repo.