On Fri, Jan 07, 2011 at 02:17:19PM -0500, Jeff King wrote: > On Fri, Jan 07, 2011 at 08:52:18PM +0200, Ilari Liusvaara wrote: > > > > > git clone --use-mirror=~/repositories/linux-2.6 git://foo.example/linux-foo > > > > This would first fetch everything from local source and then update that > > from remote, likely being vastly faster. > > I'm not clear in your example what ~/repositories/linux-2.6 is. Is it a > repo? In that case, isn't that basically the same as --reference? Or is > it a local mirror list? Yes, it is a repo. No, it isn't the same as --reference. It is list of mirrors to try first before connecting to final repository and can be any type of repository URL (local, true smart transport, smart HTTP, dumb HTTP, etc...) Idea is that you have list of mirrors that are faster than the final repository, but not necressarily complete. You want to download most of the stuff from there. > If the latter, then yeah, I think it is a good idea. Clients should > definitely be able to ignore, override, or add to mirror lists provided > by servers. The server can provide hints about useful mirrors, but it is > up to the client to decide which methods are useful to it and which > mirrors are closest. This is essentially adding mirrors to mirror list (modulo that mirrors are not assumed to be complete). Security: Confidentiality: The connection to mirror must transverse only trusted links or be encrypted if material from mirror is sensitive. Integerity: The same integerity as the connection to final repo (assuming SHA-1 can't be collided) due to fact that git object naming is securely unique. > Of course there are some servers who will want to do more than hint > (e.g., the gentoo case where they really don't want people cloning from > the main machine). For those cases, though, I think it is best to > provide the hint and to reject clients who don't follow it (e.g., by > barfing on somebody who tries to do a full clone). You have to implement > that rejection layer anyway for older clients. With option like this, a client could do: git clone --use-mirror=http://git.example.org/base/foo git://git.example.org/foo To first grab stuff via HTTP (well-packed dumb HTTP is very light on the server) and then continue via git:// (now much cheaper because client is relatively up to date). -Ilari -- 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