From: Andy Parkins <andyparkins@gmail.com>
To: git@vger.kernel.org
Cc: Julian Phillips <julian@quantumfyre.co.uk>,
Junio C Hamano <junkio@cox.net>
Subject: Re: [PATCH 0/2] bookmarks
Date: Thu, 26 Apr 2007 09:23:25 +0100 [thread overview]
Message-ID: <200704260923.26637.andyparkins@gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0704260816480.27356@beast.quantumfyre.co.uk>
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@gmail.com
next prev parent reply other threads:[~2007-04-26 8:24 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-25 19:04 git-fetch and unannotated tags Andy Parkins
2007-04-25 19:59 ` Julian Phillips
2007-04-25 20:42 ` Andy Parkins
2007-04-25 21:00 ` Junio C Hamano
2007-04-26 8:04 ` Andy Parkins
2007-04-26 15:21 ` Andreas Ericsson
2007-04-27 15:50 ` Jakub Narebski
2007-04-29 6:44 ` Junio C Hamano
2007-04-25 22:51 ` [PATCH 0/2] bookmarks (was: Re: git-fetch and unannotated tags) Julian Phillips
2007-04-25 22:25 ` [PATCH 1/2] refs.c: change do_one_ref to not discard any of base Julian Phillips
2007-04-25 22:29 ` [PATCH 2/2] Add basic support for bookmarks (create/edit/delete/list) Julian Phillips
2007-04-26 0:17 ` A Large Angry SCM
2007-04-26 0:29 ` Jeffrey C. Ollie
2007-04-26 5:53 ` [PATCH 0/2] bookmarks Junio C Hamano
2007-04-26 7:25 ` Julian Phillips
2007-04-26 7:50 ` Junio C Hamano
2007-04-26 9:04 ` Julian Phillips
2007-04-26 8:23 ` Andy Parkins [this message]
2007-04-26 8:33 ` Andy Parkins
2007-04-26 17:09 ` Petr Baudis
2007-04-26 8:08 ` [PATCH 0/2] bookmarks (was: Re: git-fetch and unannotated tags) Andy Parkins
2007-04-26 9:00 ` Julian Phillips
2007-04-26 13:45 ` Karl Hasselström
2007-04-26 16:19 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200704260923.26637.andyparkins@gmail.com \
--to=andyparkins@gmail.com \
--cc=git@vger.kernel.org \
--cc=julian@quantumfyre.co.uk \
--cc=junkio@cox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).