From: Junio C Hamano <hidden> Date: 2016-06-15 22:43:07
Julian Phillips [off-list ref] 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).
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]".
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.
From: Andy Parkins <hidden> Date: 2016-06-15 22:43:07
On Thursday 2007 April 26, Julian Phillips wrote:
quoted
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's already taken care of by the update hook. The default example that
comes with git prevents the pushing of unannotated tags, and could be
modified to prevent the pushing of any subset of refs that you wanted.
What I'm really talking about is the default functionality - we've got the
glob syntax in the config for controlling which branches get pushed, that
makes it easy to make branches that you don't want pushed. For example you
might have
[remote "origin"]
url = somewhere
push = refs/heads/publish/*:refs/heads/*
fetch = refs/heads/*:refs/remotes/origin/*
That way, only branches that I prefix with "publish/" get pushed. All I'm
after is a similar facility for tags. Unfortunately, git assumes that I'm
always going to want all tags so there is no namespace divisions I can make.
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 don't think that's unreasonable at all - even though it can be worked around
using a hook script, the problem still exists - what if I want the option to
push a certain tag, but by default I don't want it sent. For branches it's
no problem - the [remote] supplies the default and I can always do
git push origin branch
for the extras.
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.
No, no - I certainly don't want to make it public. That's the point - I want
to keep all my private things private, and hence I want to be able to control
which branches and which tags are pushed and fetched.
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?
Yes - exactly right. That's what I was trying to suggest (badly) with my
[remote "origin"]
url = whatever
fetch = refs/tags/?:refs/tags/?
suggestion.
To say it more explicitly - perhaps tags should /not/ be auto-followed, but
rather treated exactly as branches are?
Actually how about this: an option in the remote section to turn off
auto-following and then add fetch and push lines for the tags too - that
means very minimal changes and then everyone's happy (where everyone =
me ;-)).
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
From: Andy Parkins <hidden> Date: 2016-06-15 22:43:07
On Thursday 2007 April 26, Andy Parkins wrote:
Actually how about this: an option in the remote section to turn off
auto-following and then add fetch and push lines for the tags too - that
means very minimal changes and then everyone's happy (where everyone =
me ;-)).
Funny. I went looking to add the above facility, and lo-and-behold, it's
already there in the form of the remote.$remote.tagopt parameter.
[remote "origin"]
tagopt = --no-tags
push = refs/tags/public:refs/tags/*
fetch = refs/tags/*:refs/tags/public/*
This does exactly what I want. Once again, git is waaaay ahead of me :-)
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
From: Petr Baudis <hidden> Date: 2016-06-15 22:43:07
On Thu, Apr 26, 2007 at 10:33:36AM CEST, Andy Parkins wrote:
On Thursday 2007 April 26, Andy Parkins wrote:
quoted
Actually how about this: an option in the remote section to turn off
auto-following and then add fetch and push lines for the tags too - that
means very minimal changes and then everyone's happy (where everyone =
me ;-)).
Funny. I went looking to add the above facility, and lo-and-behold, it's
already there in the form of the remote.$remote.tagopt parameter.
[remote "origin"]
tagopt = --no-tags
push = refs/tags/public:refs/tags/*
fetch = refs/tags/*:refs/tags/public/*
This does exactly what I want. Once again, git is waaaay ahead of me :-)
Still, I think it would be nice to have an "out-of-the-box" general
solution for this. And since as Junio said, it might be nice to have
private heads as well, I might mention my ancient proposal to just keep
refs with filename starting with a dot (refs/tags/.foo, ...) private by
default. I have discussed this with Junio and IIRC he wasn't very happy
with this proposal, but I can't remember his arguments now. :-(
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett