Karthik Nayak <karthik.188@xxxxxxxxx> writes: > The `git refs migrate` command was introduced in > 25a0023f28 (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 feature 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: > 1. While there is REF_LOG_ONLY flag, there is no function to utilize > the flag and add reflogs. > 2. reference backends generally sort the updates by the refname. This > wouldn't work for reflogs which need to ensure that they maintain the > order of creation. > 3. In the files backend, reflog entries are added by obtaining locks > on the refs themselves. This means each update in the transaction, will > obtain a ref_lock. This paradigm fails to accompany the fact that there > could be multiple reflog updates for a refname in a single transaction. > 4. 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. Using this, we can add a new function which only adds > reflog updates to the transaction. Out of interest, I see various changes happen around committer info. But why is the committer info more relevant for reflog updates, in contrast to normal ref updates? -- Toon
