On Wed, 25 Apr 2007, Junio C Hamano wrote:
Julian Phillips <julian@xxxxxxxxxxxxxxxxx> 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.
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.
-
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