On fetch refspecs and wildcards

I was looking at t5505 tests and noticed something funny.

This is a design level question, so I am cc'ing Daniel whose remote.c is heavily involved in the new implementation.

What should this config do:

    [remote "origin"]
        url = ../one/.git
        fetch = +refs/heads/*:refs/remotes/origin/*
        fetch = refs/heads/master:refs/heads/upstream

when the other repository (../one/.git) has branches "master" and "side2"?

I am not sure if the original implementation used to copy master to both refs/remotes/origin/master and refs/heads/upstream, but I think that is what the users would expect.

I think the current one excludes any source that has an explicit destination from the wildcard matches. It is probably Ok as long as we reject if the same source has more than one destinations (or matches more than one wildcards, for that matter) like this as a configuration error:

    [remote "origin"]
        url = ../one/.git
        fetch = refs/heads/master:refs/heads/upstream
        fetch = refs/heads/master:refs/heads/another

If it doesn't, it does feel somewhat inconsistent.

Fortunately or unfortunately, Documentation/pull-fetch-param.txt does not talk about wildcard refspecs (not even the syntax, let alone the semantics), so we can define whatever we want right now, and I think both

    (1) allow duplicated destinations, including wildcard matches; and

    (2) refuse duplicated destinations for explicit ones, and more than
        one wildcard patterns that match the same ref, but omit explicitly
        specified ones from wildcard matches;

are viable options. I suspect the current code does not do either. We should pick one semantics, make sure the implementation matches that, and document it.

Another topic is what the semantics should be for mirroring configuration, like this:

    [remote "origin"]
        url = ../one/.git
        fetch = refs/*:refs/*

or

    [remote "origin"]
        url = ../one/.git
        fetch = refs/*:refs/remotes/one/*

The issues are:

 (1) get_fetch_map() currently insists on refname to be check_ref_format()
     clean; it even rejects CHECK_REF_FORMAT_ONELEVEL, which means that
     refs/stash would not be considered Ok and the code will die().

 (2) "git remote prune" seems to cull refs/remotes/one/HEAD if exists.

Currently we do not have a way to determine where HEAD at the remote points at at the protocol level (I've sent a patch to the list earlier for the necessary protocol extension on the upload-pack side, but receiver side never got implemented in remotes.c). So we cannot propagate refs/HEAD information correctly right now, but when we accept the protocol extension to do so, issue (1) will matter also for HEAD.

I think there is no design level question on this one. I think both are bugs we currently have (and they may probably not be regressions).