Miklos Vajna <vmiklos@xxxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
