馃梻 RefTable support in GitLab
reftables is a new storage data structure in Git that stores refs in a portable binary format instead of loose files or a packed-refs file. Reftables can help GitLab in two main ways.
1. performance
2. race-free ref updates
JGit already has this functionality, and Google has been running it internally. This has not yet been fully upstreamed to Git, partly because of a lack of time and resources. We can help Han-Wen get this feature over the finish line.
The code is currently here: https://github.com/git/git/pull/1215
Most of the help falls into two categories:
1. Run all of the tests with GIT_TEST_REFTABLE=1, and fix the failures.
2. Look through the code in refs/reftable-backend.c, and check what should
happen in the spots marked "XXX"
The following is from Han-Wen:
```
For 1.), it means poring over the test output with GIT_TRACE_REFS=1 in the
reftable and the traditional flavor, and understanding how they are
different. This is tedious and time consuming. It turns out that a number
of tests must have some of their test functions annotated with REFFILES.
Unfortunately, some test files are structured poorly, and you can't just
skip a single test function without causing side effects later on, so those
tests need cleanup/refactoring. Other test failures point to edge cases
that aren't handled correctly by the reftable backend. It would probably
help if each of these failures was documented in more detail, perhaps as a
REFFILES annotation with a comment.
For 2.) I've documented parts where I wasn't sure of what to do with XXX
in comments. I think the biggest open question is how to handle worktrees.
If you have a main checkout int maindir/ and a worktree in wt/, then
currently, it is setup such that there are 2 reftable databases (
maindir/.git/reftable/ and a maindir/.git/worktrees/wt/reftable/ ), which
get merged together (incorrectly, marked with XXX), but this is actually
somewhat overkill: the worktree could use loose ref storage, Also, the
merging is handled by the reftable backend, but perhaps the better approach
is to lift the merging and worktree handling into a generic layer? That is
more work, though.
```
epic