3

Somehow, I got into a state where I had some git repos that didn't have a refs directory, but did have a packed-refs file. When trying to use those repos, git would immediately error out with:

fatal: not a git repository (or any of the parent directories): .git

All I had to do was make an empty refs directory, and git would work, and even report all the information about branches stored in the packed-refs files.

Should a git repo without a refs directory, but with a packed-refs file really be considered invalid? How did my repos even get into this situation?

These repos were ones used by bundler. For example, they were at:

/usr/local/lib/ruby/gems/2.3.0/cache/bundler/git/resque-841a12220f681ab6c7edba71d186ddfb64ee193f

Removing those directories, or creating the empty refs dirs under them did the trick. It's still just confusing why this would happen.

onlynone
  • 7,602
  • 3
  • 31
  • 50
  • Possible duplicate of [How to unpack packed-refs?](https://stackoverflow.com/questions/3333255/how-to-unpack-packed-refs) – Romain Valeri Feb 04 '19 at 17:47
  • Not really a duplicate. I don't really care about unpacking them. I can just create the empty refs directory and everything works. I just want to know if it's really correct to interpret a git repo without a refs dir, but *with* a valid packed-refs file as invalid. And I'm curious as to how `bundler` and I even got into this situation since I don't ever directly interact with these repos. – onlynone Feb 04 '19 at 17:53
  • 2
    GIt's check to see if a directory is a valid repository consists of inspecting to see if it has: a valid `HEAD`, a `refs/`, and an `objects/` (or `$GIT_OBJECT_DIRECTORY`). So, yes, if the `refs/` directory is missing, Git will decide that that's not a repository. See [is_git_directory](https://github.com/git/git/blob/b5101f929789889c2e536d915698f58d5c5c6b7a/setup.c#L309-L347). (I have no idea how yours got the way it did.) – torek Feb 04 '19 at 17:54
  • It happened because Git doesn't expect to ever produce a repo that looks like yours so it it doesn't recognize yours. Whatever produced it, that's a bug, nothing confusing about it. I'm betting that 3rd-party repo wrangler did it, or somebody experimenting and getting surprised. – jthill Feb 04 '19 at 20:54
  • @torek. Yeah that does seem to be the literal reason why git fails early. But I'm also wondering why... if a line entry in `packed-refs` is considered the same as a file under the `refs` dir, maybe it would be more correct for the check to be for `refs` or `packed-refs`. And how did I even get into this situation since I'm not manually going into these paths and deleting directories, and I assume bundler is just using plain git commands to interact with these repos. – onlynone Feb 04 '19 at 21:13
  • 2
    Not directly relevant to the problem, but: packed-refs is "new" (at maybe a decade old), as a solution to the fact that some repos fill up with megabytes of tags, which take about 2% of the previous disk space once packed. Probably the `is_git_directory` code predates packed-refs files. I'm still expecting references to become a real database someday. – torek Feb 04 '19 at 21:18
  • Same problem here with some old test repos I inherited. Thanks a million for the hint of adding an empty refs directory! – Kathi May 25 '20 at 16:14

0 Answers0