Re: Pathological performance with git remote rename and many tracking refs

[Junio C Hamano <gitster@pobox.com>]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> 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?