Is it safe to rename remotes in git?

Question

I have 2 remotes - origin and remote2 one and I want to rename remote2 to origin and origin to source. Is it safe to do so? If yes, how do I do it?

Edit: By safe I mean that if some branch is tracked from "origin", will it continue to be track from "source" after rename. Also I wish I new what else could go wrong :)

Answer 1

I believe it is safe, yes, unless you have scripts referencing the remote by name for instance (in which case these will still use the old remote name).

The command is:

git remote rename <old> <new>

So if you have something tracked from foo, then rename foo to bar, it will now be tracked from bar. To check, use:

git remote -v show
git branch -a -v

before and after.

Answer 2

Also I wish I new what else could go wrong.

Not exactly "wrong", but if your remote has a log of branch/tag to update, a remote rename can be slow.

That is why, with Git 2.36 (Q2 2022), "git remote rename A B"^(man) has been taught to show progress bar while making the user wait.

See commit 56710a7, commit c6dddb3 (03 Mar 2022) by Taylor Blau (ttaylorr).
^{(Merged by Junio C Hamano -- gitster -- in commit 47c52b2, 16 Mar 2022)}

builtin/remote.c: show progress when renaming remote references

^{Suggested-by: brian m. carlson
Signed-off-by: Taylor Blau}

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 this thread, 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.

rename_ref()'s special handling to detect D/F (Directory/File) conflicts would need to be rewritten for the transaction code if we wanted to proactively catch D/F F (Directory/File) 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).

git remote now includes in its man page:

git remote rename [--[no-]progress] <old> <new>