Re: [PATCH 0/2] bookmarks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thursday 2007 April 26, Julian Phillips wrote:

> > 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@xxxxxxxxx
-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]