Re: [PATCH 2/3] Different views on a repository

From: Andreas Gruenbacher <agruen@suse.de>
Date: Feb 25, 2010, 14:35 UTC
Message-ID: <201002251535.03334.agruen@suse.de>
In-Reply-To: <4B866D60.6040306@drmicha.warpmail.net>

On Thursday 25 February 2010 13:30:24 Michael J Gruber wrote:

Show 28 quoted lines

> 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