Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
> I actually wonder if this wouldn't be that hard, because if we have any
> reflogs we could simply "replay" them by turning (again, I'm a bit rusty
> on the exact lock dance);
>
> lock(refs/remotes/origin/master);
> lock(refs/remotes/def/master);
> create(refs/remotes/def/master, refs/remotes/origin/master^{});
Why deref? Trying to be prepared for seeing a symbolic ref, or
something?
> delete(refs/remotes/origin/master);
> unlock(refs/remotes/origin/master);
> unlock(refs/remotes/def/master);
>
> Into instead doing:
>
> lock(refs/remotes/origin/master);
> lock(refs/remotes/def/master);
> for from, to, msg ref_update(refs/remotes/origin/master):
> update(refs/remotes/def/master, from, to, msg);
> delete(refs/remotes/origin/master);
> unlock(refs/remotes/origin/master);
> unlock(refs/remotes/def/master);
Would this (or the above, for that matter) work well when renaming 'foo'
to 'foo/bar' (or the other way around), I wonder?
Anyway.
Is the reasoning behind "replay each and every reflog entry" because
you are trying to avoid depending on the implementation detail (i.e.
"R=.git/logs/refs/remotes; mv $R/origin/master $R/def/master" works
only with the files backend)? Unless we are willing to add a new
ref backend method to help this natively, it would be a workable but
an ultra-slow way to do so, as it would involve open, write, fsync,
and close for each reflog entry.
... goes and looks ...
Hmph, I am utterly confused. refs/files-backend.c eventually
dispatches to files_copy_or_rename_ref() when rename_ref method in
ref_storage_be is used on the files backend, and the function
already renames the reflog file without having to copy entry by
entry. We cannot just open a transaction, run many rename_refs and
close it?
