Thread (5 messages) flat view 5 messages, 4 authors, 2016-06-15

Re: [PATCH 0/2] bookmarks

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help