馃梻 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