Skip to content

Make HEAD lookups work with reftable #2389

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

bk2204
Copy link

@bk2204 bk2204 commented Apr 2, 2025

Git has a new ref storage backend called reftable that stores all refs, including HEAD, as well as all reflogs, in a binary format under .git/reftable. Because the HEAD file is important in determining whether a directory is a Git repository, Git retains this file, but it always contains "ref: refs/heads/.invalid", thus pointing to an invalid ref, since ref components may not start with a dot.

In such a configuration, the only practical possibility is to invoke a Git command to resolve HEAD for us, so use git rev-parse to do so. Look up the object ID and the value for HEAD at the same time to avoid the overhead of two calls and use the former if the latter is HEAD (that is, we're not on a branch).

Unfortunately, this doesn't work when we have an unborn branch without any commits, such as when a repository is newly initialized. Fall back to git symbolic-ref in such a case.

Note that the head cache cannot be preserved here because the .git/HEAD file does not have to change when the branch changes with reftable (in fact, it will not), so remove that code here.

Fixes #2371

@tpope
Copy link
Owner

tpope commented Apr 2, 2025

Executing an external process every time the status line is updated (basically every keystroke) will severely impact UI responsiveness, albeit a lot more for some users than others. Is there anything we can cache on?

@bk2204
Copy link
Author

bk2204 commented Apr 2, 2025

We could cache on .git/reftable/tables.list for reftable plus always .git/HEAD. The former is the list of reftable files, so that would reflect the state of the refs database for reftable.

I can add that functionality, but it may take me a day or two to get it done.

@tpope
Copy link
Owner

tpope commented Apr 2, 2025

I would encourage you to use the command conditionally once .invalid is encountered, rather than replacing the existing implementation.

@bk2204
Copy link
Author

bk2204 commented Apr 6, 2025

Okay, I've updated this to keep the regular implemntation and only use the reftable implementation only when refs/heads/.invalid is detected. In addition, there's now a cache for the reftable file as well to make this cheaper when the branch doesn't change.

Git has a new ref storage backend called reftable that stores all refs,
including HEAD, as well as all reflogs, in a binary format under
.git/reftable.  Because the HEAD file is important in determining
whether a directory is a Git repository, Git retains this file, but it
always contains "ref: refs/heads/.invalid", thus pointing to an invalid
ref, since ref components may not start with a dot.

In such a configuration, the only practical possibility is to invoke a
Git command to resolve HEAD for us, so use git rev-parse to do so if we
find this invalid ref in the HEAD file.  Look up the object ID and the
value for HEAD at the same time to avoid the overhead of two calls and
use the former if the latter is HEAD (that is, we're not on a branch).

Unfortunately, this doesn't work when we have an unborn branch without
any commits, such as when a repository is newly initialized.  Fall back
to git symbolic-ref in such a case.

Use the regular head cache, as well as a new reftable head cache that
tracks .git/reftable/tables.list.  The reftable format uses several
binary files plus a list of tables and the table list will change
whenever a regular ref or symref (including HEAD) changes, which is what
we want to know.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

FugitiveHead() produces wrong value with reftable
2 participants