Re: How to resume broke clone ?
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Dec 5, 2013, 18:01 UTC
- Message-ID
- <xmqqeh5ri3d3.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <20131205160418.GA27869@sigill.intra.peff.net>
Jeff King <peff@peff.net> 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.
Show 9 quoted lines
>> 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).
Show 10 quoted lines
>> 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.