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

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

Andreas Gruenbacher venit, vidit, dixit 25.02.2010 10:25:

quoted

On Thursday 25 February 2010 10:01:43 Michael J Gruber wrote:

quoted

Andreas Gruenbacher venit, vidit, dixit 24.02.2010 16:57:

quoted

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