refs: add support for reflogs in `git-refs migrate`
refs: add reflog support to git refs migrate
The git refs migrate
command was introduced in 25a0023f (builtin/refs: new command to migrate ref storage formats, 2024-06-06) to support migrating from one reference backend to another.
One limitation of the command was that it didn't support migrating repositories which contained reflogs. This isn't a requirement on the server side as repositories are stored as bare repositories (which do not contain any reflogs). Clients however generally use reflogs and until now couldn't use the git refs migrate
command to migrate their repositories to the new reftable format.
One of the issues for adding reflog support is that the ref transactions don't support reflogs additions:
- While there is REF_LOG_ONLY flag, there is no function to utilize the flag and add reflogs.
- reference backends generally sort the updates by the refname. This wouldn't work for reflogs which need to follow chronological ordering.
- In the files backend, reflog entries are added by obtaining locks on the refs themselves. This breaks with multiple reflogs for the same refname.
- The backends check for duplicate entries, which doesn't make sense in the context of adding multiple reflogs for a given refname.
We overcome these issue we make the following changes:
- Update the ref_update structure to also include the committer information. This helps add reflog only updates to the transaction, helps with
1
. - Add an index field to the ref_update structure, this will help order updates in pre-defined order, this fixes
2
. - While the ideal fix for
3
would be to actually introduce reflog locks, this wouldn't be possible without backward compatibility. So we add a count to the existing ref_lock. With this, multiple reflog updates can share a single ref_lock.
Overall, this series is a bit more involved, and I would appreciate it if it receives a bit more scrutiny.
Closes #320 (closed)