Jeff King <peff@xxxxxxxx> writes: > Right, I think that's the most critical one (though you could also just > use the convention of ".bundle" in the URL). I think we may want to > leave room for more metadata, though. Good. I like this line of thinking. >> Heck, remote.origin.url might already >> be a good mirror address to advertise, especially if the client isn't >> on the same /24 as the server and the remote.origin.url is something >> like "git.kernel.org". :-) > > 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). 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. And this is why the packfile name algorithm is horribly flawed. I >> keep saying we should change it to name the pack using the last 20 >> bytes of the file but ... nobody has written the patch for that? :-) > > Totally agree. I think we could also get rid of the horrible hacks in > repack where we pack to a tempfile, then have to do another tempfile > dance (which is not atomic!) to move the same-named packfile out of the > way. If the name were based on the content, we could just throw away our > new pack if one of the same name is already there (just like we do for > loose objects). Yay. -- 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