Can a git refspec include multiple wildcards?

Question

Running git ls-remote origin on a repo I have access to, I see branches of the following form, using git namespaces.

refs/namespaces/share/refs/namespaces/<username>/refs/heads/<branch-name>

I'd like to map these to refs/remotes/<username>/<branch-name>.

This github help page gives an example of how to solve a simpler version of this problem, by adding this to the .git/config:

[remote "origin"]
    fetch = +refs/pull/*/head:refs/remotes/origin/pr/*

I can make things work for my case with:

[remote "origin"]
    fetch = +refs/namespaces/share/refs/namespaces/USER1/refs/heads/<branch-name>:refs/remotes/origin/USER1/*
    fetch = +refs/namespaces/share/refs/namespaces/USER2/refs/heads/<branch-name>:refs/remotes/origin/USER2/*
    # etc

But this requires me to know all the usernames ahead of time. Unfortunately, using two *s doesn't work:

[remote "origin"]
    fetch = +refs/namespaces/share/refs/namespaces/*/refs/heads/<branch-name>:refs/remotes/origin/*/*

Is there way of achieving this remapping?

Answer 1

No—or more precisely, not short of writing a program to write a series of fetch = lines.

You could write such a program using a sort of meta-configuration (stored in .git/config or somewhere else, it does not really matter at this level). The program would run git ls-remote on the remote, compute the appropriate fetch = lines, and update .git/config to contain them.

If you name this program, say, git-synchrofetch (this name is meant to harken back to synchromesh), you could have it invoke git fetch after updating .git/config. Then instead of git fetch origin you might run git synchrofetch origin, to update your default fetches and then fetch.

(Note that the program could also just invoke git fetch directly with a full set of refspecs, but the idea here would be to let most of the other Git code operate as normal and only do a resynchronization when you think the set of user names has changed.)