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

Martin von Zweigbergk [off-list ref] 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.

On Wed, 7 Sep 2011, Junio C Hamano wrote:

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.

Ah, of course. Sorry for being slow and thanks for the explanation. So
if there are two configured refspecs with RHSs "refs/remotes/$OLD/foo"
and "refs/remotes/$OLD/bar/*", we should remember that we updated
those and only update refs that match the same patterns. I will see
what I can do and will hopefully soon get back with a "patch 4/2".


Martin