On Thu, Dec 05, 2013 at 10:01:28AM -0800, Junio C Hamano wrote: > > You could have a "git-advertise-upstream" that generates a mirror blob > > from your remotes config and pushes it to your publishing point. That > > may be overkill, but I don't think it's possible with a > > .git/config-based solution. > > I do not think I follow. The upload-pack service could be taught to > pay attention to the uploadpack.advertiseUpstream config at runtime, > advertise 'mirror' capability, and then respond with the list of > remote.*.url it uses when asked (if we go with the pkt-line based > approach). I was assuming a triangular workflow, where your publishing point (that other people will fetch from) does not know anything about the upstream. Like: $ git clone git://git.kernel.org/pub/scm/git/git.git $ hack hack hack; commit commit commit $ git remote add me myserver:/var/git/git.git $ git push me $ git advertise-upstream origin me If your publishing point is already fetching from another upstream, then yeah, I'd agree that dynamically generating it from the config is fine. > Alternatively, it could also be taught to pay attention > to the same config at runtime, create an blob to advertise the list > of remote.*.url it uses and store it in refs/mirror (or do this > purely in-core without actually writing to the refs/ namespace), and > emit an entry for refs/mirror using that blob object name in the > ls-remote part of the response (if we go with the magic blob based > approach). Yes. The pkt-line versus refs distinction is purely a protocol issue. You can do anything you want on the backend with either of them, including faking the ref (you can also accept fake pushes to refs/mirror, too, if you really want people to be able to upload that way). But it is worth considering what implementation difficulties we would run across in either case. Producing a fake refs/mirror blob that responds like a normal ref is more work than just dumping the lines. If we're always just going to generate it dynamically anyway, then we can save ourselves some effort. -Peff -- 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