Re: [PATCH v2] upload-pack: Fail if cloning empty namespace

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

>> You create a namespace by pushing to it,...
>
> You keep repeating that, but I do not think we agreed that it is the
> supported or correct procedure to set up a new namespace in the
> first place.  Doesn't the server side need a lot more than just
> setting up HEAD symref (like running upload/receive-pack with the
> path to the hierarchy exported as GIT_NAMESPACE environment)?

Let me step back and try again, as I think I am missing some
existing feature you are using, and that missing piece is preventing
me from seeing why this is a good idea (by the way, I do not think
we are doing this exchange in the right thread---the upload-pack
patch is not about auto-vivifying a new namespace by creating HEAD).

I'll do a brief braindump which hopefully shows the basis of why I
keep saying that creating HEAD at random place is not sufficient.
Help me, by telling me what I am missing, understand why it is
sufficient.

Suppose we have a server at URL git://site.xz/r; it serves from the
filesystem, say /usr/share/git/r.git/ (bare repository).  In that
directory, we have the usual HEAD, objects, refs/{heads,tags}, etc.
Further suppose we have there refs/namespaces/a/ under which HEAD,
refs/{heads,tags}, etc.

Then we run the server (say, git-daemon) with GIT_NAMESPACE
environment variable set to 'a'.  The users can now run:

 $ git clone git://site.xz/r

and they will see what's really under refs/namespaces/a/.  The HEAD
they see is actually not /usr/share/git/r.git/HEAD but it is
/usr/share/git/r.git/refs/namespaces/a/HEAD.  Everything outside
/usr/share/git/r.git/refs/namespaces/a is not visible to them.

In order to add a new namespace 'b' next to 'a', you would somehow
need to populate /usr/share/git/r.git/refs/namespaces/b.  Presumably
you can prepare a source repository locally and then push everything
there manually, by doing something like this:

 $ git push ssh://site.xz/usr/share/git/r.git refs/*:refs/namespaces/b/*

but we agree that this does not create refs/namespaces/b/HEAD.

But if we made some change to the transfer to push-to-receive-pack
so that this can also create HEAD that points at something, what
would the user say, instead of that earlier

 $ git clone git://site.xz/r

to access this new namespace?  Don't you have to be running another
instance of a server with GIT_NAMESPACE set to 'b'?  How do you
arrange that to automagically happen?

Or do your users that clone/fetch do things differnetly from the
above, and if so what do they do?

How is your server configured to support the access the existing
namespace 'a', and the new namespace 'b' that is automatically
created by pointing /usr/share/git/r.git/refs/namespaces/b/HEAD
to one ref inside that namespace?
--
To unsubscribe from this list: send the line "unsubscribe git" in



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]