On Thu, May 23, 2024 at 4:26 AM Patrick Steinhardt <ps@xxxxxx> wrote: > With the introduction of the new "reftable" backend, users may want to > migrate repositories between the backends without having to recreate the > whole repository. Add the logic to do so. > > The implementation is generic and works with arbitrary ref storage > formats because we only use. ECANNOTPARSE: This sentence seems to be broken grammatically. > It does have a few limitations though: > > - We do not migrate repositories with worktrees, because worktrees > have separate ref storages. It makes the overall affair more complex > if we have to migrate multiple storages at once. > > - We do not migrate reflogs, because we have no interfaces to write > many reflog entries. > > - We do not lock the repository for concurrent access, and thus > concurrent writes may make use end up with weird in-between states. > There is no way to fully lock the "files" backend for writes due to > its format, and thus we punt on this topic altogether and defer to > the user to avoid those from happening. > > In other words, this version is a minimum viable product for migrating a > repository's ref storage format. It works alright for bare repos, which > typically have neither worktrees nor reflogs. Worktrees hanging off a bare repository is an explicitly supported use-case, and there are people who use and promote such an organization, so I'm not sure if "typically" is accurate these days. Anyhow, just a minor observation, probably not worth rewording, and certainly not worth a reroll. > But it will not work for > many other repositories without some preparations. These limitations are > not set into stone though, and ideally we will eventually address them > over time. > > The logic is not yet used by anything, and thus there are no tests for > it. Those will be added in the next commit. > > Signed-off-by: Patrick Steinhardt <ps@xxxxxx>
