Re: [PATCH 0/3] symref rename/delete fixes

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

Miklos Vajna <vmiklos@frugalware.org> writes:

> A symref-aware rename_ref() is needed by git remove rename, since it
> typically does origin/HEAD -> upstream/HEAD symref renames there.
>
> Of course you can say that this should be handled by git-remote itself,
> without using rename_ref() but that not seem to be a good solution to
> me. (Workaround in the wrong layer, instead of a solution in a good
> one.)

I do not think it is a workaround at all.

I would even say that the renaming of symref that "git remote rename"
needs to do is fundamentally different from what rename_ref() is about,
and trying to cram it into rename_ref() is a grave mistake.

If you "git remote rename origin upstream" when origin/HEAD points at
refs/remotes/origin/master, you need to make the renamed one point at
refs/remotes/upstream/master, as you will be renaming origin/master to
upstream/master.

Normal "rename_ref()" would just rename the ref without touching its
contents, and if you used it to implement "git remote rename", your
upstream/HEAD would point at the old name "origin/master" that will
disappear when rename is finished, wouldn't it?  I do not think it is
useful.

There may be cases where you would really want to rename the symbolic ref
without changing its value (e.g. which other ref it points at), but as you
mentioned, even "git branch -m" is not such a usecase.

I think it is better to simply forbid renaming of a symref _until_ we know
what we want it to mean.  It is a lot easier to start strict and then add
features, than start loosely and implement an unclean semantics, and then
having to fix that semantics after people start to rely on the initial
(potentially crazy) semantics.