summaryrefslogtreecommitdiff
path: root/sha256/block
diff options
context:
space:
mode:
authorLibravatar Taylor Blau <me@ttaylorr.com>2022-03-03 17:25:18 -0500
committerLibravatar Junio C Hamano <gitster@pobox.com>2022-03-03 14:44:05 -0800
commit56710a7ae0170404d7bc6411bd5c9a18124c0629 (patch)
treee4b772e965549944708a92125039fa0e91c83631 /sha256/block
parentbuiltin/remote.c: parse options in 'rename' (diff)
downloadtgif-56710a7ae0170404d7bc6411bd5c9a18124c0629.tar.xz
builtin/remote.c: show progress when renaming remote references
When renaming a remote, Git needs to rename all remote tracking references to the remote's new name (e.g., renaming "refs/remotes/old/foo" to "refs/remotes/new/foo" when renaming a remote from "old" to "new"). This can be somewhat slow when there are many references to rename, since each rename is done in a separate call to rename_ref() as opposed to grouping all renames together into the same transaction. It would be nice to execute all renames as a single transaction, but there is a snag: the reference transaction backend doesn't support renames during a transaction (only individually, via rename_ref()). The reasons there are described in more detail in [1], but the main problem is that in order to preserve the existing reflog, it must be moved while holding both locks (i.e., on "oldname" and "newname"), and the ref transaction code doesn't support inserting arbitrary actions into the middle of a transaction like that. As an aside, adding support for this to the ref transaction code is less straightforward than inserting both a ref_update() and ref_delete() call into the same transaction. rename_ref()'s special handling to detect D/F conflicts would need to be rewritten for the transaction code if we wanted to proactively catch D/F conflicts when renaming a reference during a transaction. The reftable backend could support this much more readily because of its lack of D/F conflicts. Instead of a more complex modification to the ref transaction code, display a progress meter when running verbosely in order to convince the user that Git is doing work while renaming a remote. This is mostly done as-expected, with the minor caveat that we intentionally count symrefs renames twice, since renaming a symref takes place over two separate calls (one to delete the old one, and another to create the new one). [1]: https://lore.kernel.org/git/572367B4.4050207@alum.mit.edu/ Suggested-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'sha256/block')
0 files changed, 0 insertions, 0 deletions