On Thu, 26 Apr 2007, Junio C Hamano wrote:
Julian Phillips <julian@xxxxxxxxxxxxxxxxx> writes:
That way you are not reliant on the user's tools following your rules.
You misunderstood -- what implements the rules is on the
repository side, not the end users' side.
If your public repo is available via http or rsync, then you can't
consider anything private ...
If it's available via git:// only, then that's different.
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 wouldn't have bothered to jump into the thread if this were
about public repositories. You would not even need a separate
namespace refs/bm -- you do not have to push that out.
If the repository is not public, where's the problem? _Everthing_ is
private then...
(by public I simply mean "availabe for others to fetch from")
But that was not what Andy was talking about.
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.
You misunderstood. I am not talking about updating ls-remote.
The update to upload-pack/update-server-info is done on the side
of Andy's repository, not on the client side.
Yeah, that's what I get for trying to think before lunch time ... :$
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?
You do not have to update anything on push side, as push just
pushes what you tell it to, unless you say 'push --all', in
which case you obviously mean all is all is all, so there is no
need for exclude.
Having thought about after I sent my email, I agree that the current push
syntax is already enough.
--
Julian
---
BOFH Excuse #56:
Electricians made popcorn in the power supply
-
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