Avoid crashing when run in a bare git repo that somehow contains an index file

Do not populate the keys database with associated files,
because a bare repo has no working tree, and so it does not make sense to
populate it.

Queries of associated files in the keys database always return empty lists
in a bare repo, even if it's somehow populated. One way it could be
populated is if a user converts a non-bare repo to a bare repo.

Note that Git.Config.isBare does a string comparison, so this is not free!
But, that string comparison is very small compared to a sqlite query.

Sponsored-by: Erik Bjäreholt on Patreon
This commit is contained in:
Joey Hess 2022-01-11 13:01:49 -04:00
parent c031d19c32
commit f54c58f0df
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
4 changed files with 48 additions and 4 deletions

View file

@ -55,3 +55,4 @@ AFAICS this creates the same records as if I would have done this in a regular w
Is this a bug, or am I doing something wrong? Thanks in advance for your time!
> [[fixed|done]] --[[Joey]]

View file

@ -0,0 +1,28 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2022-01-11T16:25:50Z"
content="""
`git update-index` creates an index file. A repo with an index file is no
longer a bare repo to a certain extent, at least it is very unusual for a
repo to be both bare and contain an index file, since after all an index
file is a record of the files in the working tree. This seems to be the root
of the confusion.
I was able to reproduce this by simply copying `.git/index` from a non-bare
repo into the bare repo and then running `git-annex drop --all`.
Removing the index file was not sufficient to fix it. It turned out I also
needed to delete `annex/keydb*`. Then things returned to normal.
So, it seems that the keys database is getting populated in a bare repo
when there's an index file, and once the keys database is populated, it
runs code paths that will not work in a bare repo, because that database
contains paths (taken from the index) that it treats as being present in a
nonexistant working tree. I've fixed it to both avoid populating the keys
database, and ignore a populated keys database in this situation.
But.. My suggestion is, if you need to do this kind of thing in a bare repo,
set `GIT_INDEX_FILE` to some other file. That's how git-annex makes similar
tree objects.
"""]]