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).
--
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
