Why does the number of commits increase after git lfs migrate?

Question

I tried running git lfs migrate import --everything --include="*.dll" on a large repository. Before I ran this there were about 70k commits. After running the migration (and expiring reflog and pruning etc) git rev-list --all --count shows around 130k commits. Why are there so many commits added, and what are those commits?

Answer 1

Check if the issue 3238 is not the cause in your case.
In short, a tag might still reference an old commit (and all its parents would still be counted by git rev-list )

Search if there are some tags that are still pointing to old OIDs that are suppposed to get migrated by git lfs migrate .
You get such information into the --object-map=mapping_file.map.txt file.
Following script shall be executed within git repository. It will not make any modification in the repository, until you un-echo the git tag command...

MAP_FILE=../mapping_file.map.txt
git for-each-ref | grep tags | while read -r oid type tag; do
        while IFS=, read -r old_oid new_oid; do
                if [[ "$oid" == "$old_oid" ]]; then
                        echo TAG $tag still pointing to old_oid $old_oid instead of $new_oid
                        echo git tag -f $(basename $tag) $new_oid
                fi
        done < $MAP_FILE
done

Note, the mapfile comes from this comment :

Under some specific conditions, which I don't know, lfs migrate import is not able to move refs (tags, branches) from the old commit to the new created one.
As a consequence of this, " git gc " can't remove the old commits.
Our database are unfortunately not sharable, but I can try to describe our way to get rid of these old commits.

1. Create a map file ( --object-map= ) while running lfs migrate import to get a correlation between old commits and new commits created by lfs.
2. Collect all commits from your original database and the working lfs database ( git rev-list –all )
3. Identify all so-called double commits. These are commits existing in the original and the working lfs database.
4. Check these double commits for still existing refs ( git show –s ) and move every found ref manually or by script to the corresponding new commit (from your created map file) with these git commands: git tag –f , git update-ref .
5. Run git gc –prune=now and check your commit count in your working lfs database

Answer 2

I managed to figure it out with the help of the comments from @torek. As mentioned in a comment above, git rev-list --branches --tags listed the correct number of commits.

The repository was created by using git tfs to convert a TFVC repository to git. Running git for-each-ref listed a bunch refs under refs/remotes/tfs , that did not show up when running git remote -v , due to the fact that these were listed as commits . So probably these referenced a bunch of the old commits that were not rewritten by git lfs migrate , and obviously the refs were not updated by git lfs migrate as sould probably be expected.

Deleting all of these refs using git update-ref -d , and then doing another gc, seems to have fixed the problem and the repository was back to its original number of commits.