Re: [PATCHv2 1/2] remote: write correct fetch spec when renaming remote 'remote'

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 8, 2011, 03:43 UTC
Message-ID: <7vzkifzol6.fsf@alter.siamese.dyndns.org>
In-Reply-To: <alpine.DEB.2.00.1109062136350.12564@debian>

Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:

> same pattern both when updating refspecs and when renaming refs. Of
> course, we can never be certain that a ref "refs/remotes/origin/foo"
> is really related to the remote called "origin". The user could have
> simply created the ref manually. Is that what you are getting at?

You have two separate and independent code that are not linked together but should logically be.

One updates fetch refspec whose RHS is "refs/remotes/$OLD/<anything>" to "refs/remotes/$NEW/<the same thing>". If you do not find any such fetch refspec, then you do not update these configuration variables, which is good.

Later in the same mv() function, the other one renames refs/remotes/$OLD/ to refs/remotes/$NEW/, even when you did not find any fetch refspec that stores under "refs/remotes/$OLD/<anything>" in the earlier logic.

Now, these actual refs may have been placed manually by the user. They may have been placed by an old config that the user may have edited. You simply do not know.

But you know one thing. You _do_ know is that these refs did _not_ come from any "[remote "$OLD"] fetch = ..." configuration, and by inference, it will not come from any "[remote "$NEW"] fetch = ...", in other words, they do not have any relation with the "$NEW" remote. So I do not see a good reason to move them from refs/remotes/$OLD/ to refs/remotes/$NEW/. That was what I was pointing out.