git lfs migrate info fails with "bad revision"

[jjgod]

$ git clone https://github.com/behdad/harfbuzz.git
$ cd harfbuzz
$ git lfs migrate info
Error in git rev-list --reverse --topo-order --do-walk master ^refs/remotes/origin/accelerate-lookups ^refs/remotes/origin/gh-pages ^refs/remotes/origin/gi-identfilter ^refs/remotes/origin/master ^refs/remotes/origin/wip-unsafe-to-break ^refs/tags/0.6.0 ^refs/tags/0.6.0^{} ^refs/tags/0.9.10 ^refs/tags/0.9.10^{} ^refs/tags/0.9.11 ^refs/tags/0.9.11^{} ^refs/tags/0.9.12 ^refs/tags/0.9.12^{} ^refs/tags/0.9.13 ^refs/tags/0.9.13^{} ^refs/tags/0.9.14 ^refs/tags/0.9.14^{} ^refs/tags/0.9.15 ^refs/tags/0.9.15^{} ^refs/tags/0.9.16 ^refs/tags/0.9.16^{} ^refs/tags/0.9.17 ^refs/tags/0.9.17^{} ^refs/tags/0.9.18 ^refs/tags/0.9.18^{} ^refs/tags/0.9.19 ^refs/tags/0.9.19^{} ^refs/tags/0.9.2 ^refs/tags/0.9.2^{} ^refs/tags/0.9.20 ^refs/tags/0.9.20^{} ^refs/tags/0.9.21 ^refs/tags/0.9.21^{} ^refs/tags/0.9.22 ^refs/tags/0.9.22^{} ^refs/tags/0.9.23 ^refs/tags/0.9.23^{} ^refs/tags/0.9.24 ^refs/tags/0.9.24^{} ^refs/tags/0.9.25 ^refs/tags/0.9.25^{} ^refs/tags/0.9.26 ^refs/tags/0.9.26^{} ^refs/tags/0.9.27 ^refs/tags/0.9.27^{} ^refs/tags/migrate: Sorting commits: ..., done
0.9.28 ^refs/tags/0.9.28^{} ^refs/tags/0.9.29 ^refs/tags/0.9.29^{} ^refs/tags/0.9.3 ^refs/tags/0.9.3^{} ^refs/tags/0.9.30 ^refs/tags/0.9.30^{} ^refs/tags/0.9.31 ^refs/tags/0.9.31^{} ^refs/tags/0.9.32 ^refs/tags/0.9.32^{} ^refs/tags/0.9.33 ^refs/tags/0.9.33^{} ^refs/tags/0.9.34 ^refs/tags/0.9.34^{} ^refs/tags/0.9.35 ^refs/tags/0.9.35^{} ^refs/tags/0.9.36 ^refs/tags/0.9.36^{} ^refs/tags/0.9.37 ^refs/tags/0.9.37^{} ^refs/tags/0.9.38 ^refs/tags/0.9.38^{} ^refs/tags/0.9.39 ^refs/tags/0.9.39^{} ^refs/tags/0.9.4 ^refs/tags/0.9.4^{} ^refs/tags/0.9.40 ^refs/tags/0.9.40^{} ^refs/tags/0.9.41 ^refs/tags/0.9.41^{} ^refs/tags/0.9.42 ^refs/tags/0.9.42^{} ^refs/tags/0.9.5 ^refs/tags/0.9.5^{} ^refs/tags/0.9.6 ^refs/tags/0.9.6^{} ^refs/tags/0.9.7 ^refs/tags/0.9.7^{} ^refs/tags/0.9.8 ^refs/tags/0.9.8^{} ^refs/tags/0.9.9 ^refs/tags/0.9.9^{} ^refs/tags/1.0.0 ^refs/tags/1.0.0^{} ^refs/tags/1.0.1 ^refs/tags/1.0.1^{} ^refs/tags/1.0.2 ^refs/tags/1.0.2^{} ^refs/tags/1.0.3 ^refs/tags/1.0.3^{} ^refs/tags/1.0.4 ^refs/tags/1.0.4^{} ^refs/tags/1.0.5 ^refs/tags/1.0.5^{} ^refs/tags/1.0.6 ^refs/tags/1.0.6^{} ^refs/tags/1.1.0 ^refs/tags/1.1.0^{} ^refs/tags/1.1.1 ^refs/tags/1.1.1^{} ^refs/tags/1.1.2 ^refs/tags/1.1.2^{} ^refs/tags/1.1.3 ^refs/tags/1.1.3^{} ^refs/tags/1.2.0 ^refs/tags/1.2.0^{} ^refs/tags/1.2.1 ^refs/tags/1.2.1^{} ^refs/tags/1.2.2 ^refs/tags/1.2.2^{} ^refs/tags/1.2.3 ^refs/tags/1.2.3^{} ^refs/tags/1.2.4 ^refs/tags/1.2.4^{} ^refs/tags/1.2.5 ^refs/tags/1.2.5^{} ^refs/tags/1.2.6 ^refs/tags/1.2.6^{} ^refs/tags/1.2.7 ^refs/tags/1.2.7^{} ^refs/tags/1.3.0 ^refs/tags/1.3.0^{} ^refs/tags/1.3.1 ^refs/tags/1.3.1^{} ^refs/tags/1.3.2 ^refs/tags/1.3.2^{} ^refs/tags/1.3.3 ^refs/tags/1.3.3^{} ^refs/tags/1.3.4 ^refs/tags/1.3.4^{} ^refs/tags/1.4.0 ^refs/tags/1.4.0^{} ^refs/tags/1.4.1 ^refs/tags/1.4.1^{} ^refs/tags/1.4.2 ^refs/tags/1.4.2^{} ^refs/tags/1.4.3 ^refs/tags/1.4.3^{} ^refs/tags/1.4.4 ^refs/tags/1.4.4^{} ^refs/tags/1.4.5 ^refs/tags/1.4.5^{} ^refs/tags/1.4.6 ^refs/tags/1.4.6^{} ^refs/tags/1.4.7 ^refs/tags/1.4.7^{} ^refs/tags/hb-rename ^refs/tags/hb-rename^{} ^refs/tags/ng-mergepoint ^refs/tags/ng-mergepoint^{} ^refs/tags/ng-start ^refs/tags/ng-start^{} ^refs/tags/pango-extractpoint ^refs/tags/pango-extractpoint^{} ^refs/tags/pango-start ^refs/tags/pango-start^{} --: exit status 128 fatal: bad revision '^refs/tags/1.4.3'

$ git version
git version 2.13.2 (Apple Git-90)

$ git lfs version
git-lfs/2.2.1 (GitHub; darwin amd64; go 1.8.3; git 621d1f82)

[ttaylorr]

I am unable to reproduce this:

~/D/harfbuzz (master) $ git lfs migrate info
migrate: Sorting commits: ..., done
migrate: Rewriting commits: NaN% (0/0), done

Can you retry this with --include-ref= and/or --exclude-ref=? For more info on those: see git-lfs-migrate(1).

[jjgod]

I suspect that's specific to git version.

git lfs migrate info --include-ref=master doesn't show error but it only shows me:

$ git lfs migrate info --include-ref=master
migrate: Sorting commits: ..., done                                                                                                                                                      
migrate: Rewriting commits: 100% (4598/4598), done

so it doesn't provide any info either.

[ttaylorr]

so it doesn't provide any info either.

Are there any files in this repo that are larger than the default minimum size requirement of 1mb?

From git-lfs-migrate(5):

* `--above=<size>`
    Only count files whose individual filesize is above the given size. 'size'
    may be specified as a number of bytes, or a number followed by a storage
    unit, e.g., "1b", "20 MB", "3 TiB", etc.

    If a set of files sharing a common extension has no files in that set whose
    individual size is above the given `--above` (or its default, 1mb), no files
    no entry for that set will be shown.

[jjgod]

I see. Probably not.

[ttaylorr]

@jjgod I am going to close this for now, since I am unable to reproduce the failure on Git 2.13.2, even after changing my local Git installation to match.

If you find any more details or ways to reproduce this reliably, please don't hesitate to reopen this. Thanks!

[jjgod]

Thanks for look into this!

[guneyozsan]

Hey @ttaylorr , reviving this as I hit the exact same problem.
git version 2.19.1.windows.1
git lfs version git-lfs/2.6.0 (GitHub; windows amd64; go 1.11.1; git 93702d75)
What I can add as information is the error hits the older tags that don't have the large files. My config is like this:

• Create a repository that uses git-flow.
• Set origin on GitLab, and add GitHub as the second origin url (fetches from GitLab).
• Make some feature branches (without any large file and without git lfs).
• Finish features.
• Make releases with version tags.
• After some point add some large files to feature branch.
• Finish and merge it to develop.
• Install git lfs and track large files.
• Commit .gitattribute to develop.
• Run git lfs migrate info and you hit the exact error pointing to some tag.
  (in my case I tried to import files using git lfs migrate import --include="TriLib\Plugins\**\*.bc".)
• Deleting the tag and running the same throws an error pointing to another tag.
• git lfs migrate info --include-ref=v0.1.0 (or =master) runs fine with a list like *.unity 4.0 MB 44/44 files(s) 100%. Here v0.1.0 is the tag mentioned in the error.

So where to go from here?

[TravisHeeter]

@guneyozsan Instead of deleting the tag, I ran git lfs migrate info --include-ref=v#.#.# then I stashed and pulled from SourceTree and it worked. Here's an answer I posted on Stack Overflow with a very detailed description of what I did to get mine working again: https://stackoverflow.com/a/54221959/1152809

[guneyozsan]

@TravisHeeter Thank you. I reached a similar solution and did git lfs migrate import --include="TriLib\Plugins\**\*.bc" --include-ref=master. Then I found that git lfs migrate import --everything --include="TriLib\Plugins\**\*.bc" does the same but for all branches.

This also moves the tags to the rewritten history. So I had to delete all tags from remote and perform a force push.

Unfortunately there is a huge information pollution on how to implement git-lfs to a repository with already commited large files. I think it is due to lack of clarity and focus on documentation (or accessibility of it as the last thing I came across online was the official documentation of migrate).

After starting this command I was horrified to unexpectedly see all tags and branches being rewritten history without a warning. Especially considering BFG's quite informative and cautious documentation, I just thought git-lfs lacks necessary amount of guidance and warnings about the consequences.

For anyone the examples on the official documentation of git-lfs migrate also helped:
https://github.com/git-lfs/git-lfs/blob/master/docs/man/git-lfs-migrate.1.ronn

[guneyozsan]

@TravisHeeter Although I resolved it locally with git lfs status, git lfs track, git lfs ls-files listing the files correctly, still I couldn't manage to have GitHub accept the push until I start over from the backup, commit .gitignore first, and manually re-commit the branch with large files by applying patches without commit and then staging. That was really harsh and cost 1.5 work days to resolve.

I totally understand your note "More Horror" on stackoverflow link. Anyway thanks a lot.

[thomasdeniau]

Hitting this with git 2.32.0 / git-lfs/3.1.2

[1-alex98]

Hitting this in git 2.38.0 and lfs git-lfs/3.2.0

[bk2204]

If you're seeing this, please follow the directions in the contributing documentation and open a new issue. Commenting on a closed issue is not helpful, since the issue you're seeing has a different root cause from the one fixed here.