Re: [PATCH 0/2] bookmarks

From: Julian Phillips <julian@quantumfyre.co.uk>
Date: Apr 26, 2007, 07:25 UTC
Message-ID: <Pine.LNX.4.64.0704260816480.27356@beast.quantumfyre.co.uk>
In-Reply-To: <7vmz0vu1fc.fsf@assigned-by-dhcp.cox.net>

On Wed, 25 Apr 2007, Junio C Hamano wrote:

Show 21 quoted lines

> Julian Phillips <julian@quantumfyre.co.uk> writes:
>
>> While I like the idea of private tags, I find the idea of them having
>> their own namespace to be much more attractive than simply having the
>> ability to not export lightweight tags.
>>
>> In particular it means that you can control which tags are exported
>> individually.
>
> I do not think this is limited to tags. Sometimes you may want
> to make some branches private.  It probably is also a good idea
> to hide StGIT patch base refs that live under $GIT_DIR/refs/.
>
> Here, I do not use the word "private" in the sense of being
> "secret", as most likely branches that share common root would
> have many trees and blobs in common, but in the sense of "less
> clutter".
>
> How would one find out about remote refs?  By running
> ls-remote.  And that happens to also be how git-fetch follows
> tags (the original issue Andy had).

Surely though, what you really want is to simply not put the private refs into a public repo. So the thing to be controlling is push, not fetch.

That way you are not reliant on the user's tools following your rules.

I don't think it unreasonable to say that anything that is in a public repository is public, and that the way to keep things private is to not push them into a public repository. Or is it?

I understand that some people may wish to make their working repositories public, but then there isn't any way we can say for sure that things will remain private. Even if ls-remote was updated, an older version would simply ignore the new "this is private" configuration.

Show 25 quoted lines

>
> Over native git protocol, upload-pack is the program that runs
> in the repote repository and gives list of available refs and
> object names they point at (upload-pack.c::send_ref()).  To dumb
> clients, update-server-info creates the equivalent information
> in $GIT_DIR/info/refs and that is what the ls-remote sees.
>
> So I suspect that a more general solution would be to to teach
> these two programs to take notice of a new configuration
> variable you can set in the repository to limit the set of refs
> to give out.  Then you do not have to introduce a new namespace,
>
> Probably the configuration would be a glob pattern (for pathname
> like things, we tend to use shell glob, not regexp) to
> include/exclude.  E.g.
>
> 	refs.expose = refs/heads/*
>        refs.expose = refs/tags/*
>        refs.expose = !refs/heads/*/*
>        refs.expose = !refs/tags/v[0-9]*
>
> would let you say "I would want to expose all of refs/heads/
> (i.e. branches) and refs/tags (i.e. tags), but I do not want to
> show branches with '/' in their names, nor tags whose names do
> not begin with v[0-9]".

or simply expand the current push configuration to accept that syntax, so that you can finely control which refs get pushed to the public repo?

-- 
Julian

  ---
Only two of my personalities are schizophrenic, but one of them is
paranoid and the other one is out to get him.