From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: "Shawn Pearce" <spearce@spearce.org>,
"Duy Nguyen" <pclouds@gmail.com>,
"zhifeng hu" <zf@ancientrocklab.com>,
"Karsten Blees" <karsten.blees@gmail.com>,
"Trần Ngọc Quân" <vnwildman@gmail.com>,
"Git Mailing List" <git@vger.kernel.org>
Subject: Re: How to resume broke clone ?
Date: Thu, 05 Dec 2013 10:01:28 -0800 [thread overview]
Message-ID: <xmqqeh5ri3d3.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20131205160418.GA27869@sigill.intra.peff.net> (Jeff King's message of "Thu, 5 Dec 2013 11:04:18 -0500")
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.
>> 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.
next prev parent reply other threads:[~2013-12-05 18:01 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-28 3:13 How to resume broke clone ? zhifeng hu
2013-11-28 7:39 ` Trần Ngọc Quân
2013-11-28 7:41 ` zhifeng hu
2013-11-28 8:14 ` Duy Nguyen
2013-11-28 8:35 ` Karsten Blees
2013-11-28 8:50 ` Duy Nguyen
2013-11-28 8:55 ` zhifeng hu
2013-11-28 9:09 ` Duy Nguyen
2013-11-28 9:29 ` Jeff King
2013-11-28 10:17 ` Duy Nguyen
2013-11-28 19:15 ` Shawn Pearce
2013-12-04 20:08 ` Jeff King
2013-12-05 6:50 ` Shawn Pearce
2013-12-05 13:21 ` Michael Haggerty
2013-12-05 15:11 ` Shawn Pearce
2013-12-05 16:12 ` Jeff King
2013-12-05 16:04 ` Jeff King
2013-12-05 18:01 ` Junio C Hamano [this message]
2013-12-05 19:08 ` Jeff King
2013-12-05 20:28 ` [PATCH] pack-objects: name pack files after trailer hash Jeff King
2013-12-05 21:56 ` Shawn Pearce
2013-12-05 22:59 ` Junio C Hamano
2013-12-06 22:18 ` Jeff King
2013-12-16 7:41 ` Michael Haggerty
2013-12-16 19:04 ` Jeff King
2013-12-16 19:19 ` Jonathan Nieder
2013-12-16 19:28 ` Jeff King
2013-12-16 19:37 ` Junio C Hamano
2013-12-16 19:33 ` Junio C Hamano
2013-12-16 19:35 ` Jeff King
2013-11-28 9:20 ` How to resume broke clone ? Tay Ray Chuan
2013-11-28 9:29 ` zhifeng hu
2013-11-28 19:35 ` Shawn Pearce
2013-11-28 21:54 ` Jakub Narebski
-- strict thread matches above, loose matches on Subject: below --
2013-11-28 8:32 Max Kirillov
2013-11-28 9:12 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqeh5ri3d3.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=karsten.blees@gmail.com \
--cc=pclouds@gmail.com \
--cc=peff@peff.net \
--cc=spearce@spearce.org \
--cc=vnwildman@gmail.com \
--cc=zf@ancientrocklab.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.