On Thursday 25 February 2010 13:30:24 Michael J Gruber wrote: > Andreas Gruenbacher venit, vidit, dixit 25.02.2010 10:25: > > On Thursday 25 February 2010 10:01:43 Michael J Gruber wrote: > >> Andreas Gruenbacher venit, vidit, dixit 24.02.2010 16:57: > >>> Add --view options in upload-pack and receive-pack so that a repository > >>> on the server side can be made to look like several independent > >>> repositories on the client side. > >>> > >>> This is implemented by transforming ref names: for example, with > >>> --view=one/, refs/heads/one/master on the server will look like > >>> refs/heads/master to the client, refs/tags/one/v1 will look like > >>> refs/tags/v1, etc. > >>> > >>> This allows to transparently share repositories on the server which > >>> have a lot of objects in common without complicating things for the > >>> client, and without breaking garbage collection. > >> > >> Just from this description, I can't see why the same can't be done with > >> appropriate refspecs. (A helper for doing that would be more welcome, of > >> course.) > > > > You mean on the client side? The problem then is that a simple "git > > clone" would not do the right thing anymore; you would still expose > > server-side implementation details to clients. Clients shouldn't have to > > bother with this added complexity. (They might not even have access to > > some of the views.) When you do the mapping server-side, you can split or > > merge repositories as needed without the clients even noticing. > > But the client has to request a specific view, doesn't it? No, it's a server side thing. The git commands affected are upload-pack and receice-pack, and those run on the remote end of a fetch. For example, the client would ask the server for repository /foo/one or /foo/two, and the server would map that to different views of /bar/shared: when the client asks the server to run "git-upload-pack /foo/one", the server runs "git-upload-pack --view=one/ /bar/shared" instead. This is relatively easy to set up over ssh using a simple script; for direct git access, a small wrapper daemon would be needed. I'm not sure how this could be hacked into http access, but it doesn't seem all that hard, either. > I just can't help the impression that this is a use case which does not > need a new feature, at least not upload/receive-pack wise. Still, even with the additional explanation above? > It's more a matter of ensuring that all clients use a specific configuration > (which you would have to with your patch as well, AFAICT), and this more > general issue is creeping up again and again, with no agreeable solution > so far. Well that's another problem which we indeed also have for enabling things like local consistency checks and merge drivers. I don't have a good answer here :) Thanks, Andreas -- 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