git-fetch and unannotated tags

git-fetch and unannotated tags

[Andy Parkins]

Hello,

I often use unannotated tags to mark particular revisions in a 
repository.  I use unannotated tags just as I would a bookmark.  
Annotated tags I reserve for information about a particular revision 
that I want to share with the world.  In essence I treat unannotated 
tags as private and annotated tags as public.

Unfortunately, git doesn't help me with this.  When I fetch from a 
repository that has unannotated tags, those tags are transferred.

Is there any way to stop this?  I'm fine with git doing automatic 
transfer of annotated tags, but not the unannotated.  The only way I 
can get around this is to use branches instead, that way whether they 
are transferred or not is completely under my control.

That makes me think that perhaps we should remove the special treatment 
of tags and treat them just like any other ref...

[remote "origin"]
  url = whatever
  fetch = refs/tags/*:refs/tags/*

However that still doesn't distinguish between annotated and 
unannotated.  Maybe two different glob tokens?

[remote "origin"]
  url = whatever
  fetch = refs/tags/?:refs/tags/?

Would mean annotated tags only...




Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Re: git-fetch and unannotated tags

[Julian Phillips]

On Wed, 25 Apr 2007, Andy Parkins wrote:

> Hello,
>
> I often use unannotated tags to mark particular revisions in a
> repository.  I use unannotated tags just as I would a bookmark.
> Annotated tags I reserve for information about a particular revision
> that I want to share with the world.  In essence I treat unannotated
> tags as private and annotated tags as public.

Why not create a directory .git/refs/bm and put things you don't want to 
make public in there?  You can then use bm/foo etc ...

You could even modify git-tag to create them for you with some appropriate 
switch ...

-- 
Julian

  ---
First Rule of History:
 	History doesn't repeat itself -- historians merely repeat each other.

Re: git-fetch and unannotated tags

[Andy Parkins]

On Wednesday 2007, April 25, Julian Phillips wrote:

> Why not create a directory .git/refs/bm and put things you don't want
> to make public in there?  You can then use bm/foo etc ...

I could, but then they don't get treated as tags properly in qgit.  I 
still want to list them in git-tag -l

> You could even modify git-tag to create them for you with some
> appropriate switch ...

Well yes, but that's the answer to everything isn't it?


Andy

-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Re: git-fetch and unannotated tags

[Junio C Hamano]

Andy Parkins <andyparkins@gmail.com> writes:

>> You could even modify git-tag to create them for you with some
>> appropriate switch ...
>
> Well yes, but that's the answer to everything isn't it?

The answer to everything you want to change the current
behaviour is to code something that implement that change.  What
else is new?

I suspect that if you look at what git-fetch.sh does in the
paragraph that follows /^# automated tag following/, it probably
is not that much change.  At that point,

 (1) $ls_remote_result contains the output from "git ls-remote $URL"
     we ran earlier, LF and everything intact.

 (2) show-ref --exclude-existing=refs/tags/ discards, out of
     $ls_remote_result, everything that does not begin with refs/tags/,
     and at the same time, discards the ones you already have.
     This is done after stripping away ^{} markers.

 (3) The remainder is fed to the while loop, which says "if we
     already have the object pointed at by a surviving ref under
     refs/tags/ in the remote, follow that tag".

So I think you could filter out the ones that do not have
corresponding ^{} in $ls_remote_result from the while loop.  As
the use of "show-ref --exclude-existing" is to speed things up
by reducing the work done in the while loop written in shell, I
would suggest giving another option to show-ref that can be used
together with --exclude-existing.

Take a look at exclude_existing() function in builtin-show-ref.c;
your additional option to the command would say something like:

  - ignore everything that do not begin with match (as we do now
    already);

  - if we do not have the ref we read from the stdin (determined
    with the call to path_list_has_path() there), instead of
    running printf() unconditionally as we do now, make sure we
    have both refs/tags/foo and refs/tags/foo^{} in the input.
    And show only those.

Re: git-fetch and unannotated tags

[Andy Parkins]

On Wednesday 2007 April 25, Junio C Hamano wrote:

> >> You could even modify git-tag to create them for you with some
> >> appropriate switch ...
> >
> > Well yes, but that's the answer to everything isn't it?
>
> The answer to everything you want to change the current
> behaviour is to code something that implement that change.  What
> else is new?

Apologies - I wasn't saying that someone else should add features I want, I 
was saying that locally changing /my/ git-tag isn't very useful.  I already 
get by with git, so when I post suggestions to the mailing list it's usually 
with respect to the wider context.   In this case, patching git-tag to create 
refs/andys-private-tags/ doesn't seem like the right thing to do in mainline 
git :-)

> I suspect that if you look at what git-fetch.sh does in the
> paragraph that follows /^# automated tag following/, it probably
> is not that much change.  At that point,
 ... snip ...

That advice on the other hand is excellent.

Is this something that others would be in favour of?  I'm soliciting for 
reasons why unannotated tags should be auto-followed?

> Take a look at exclude_existing() function in builtin-show-ref.c;
> your additional option to the command would say something like:

I'd be arguing for making not following unannotated tags the default, and then 
supply a switch to make them followed.  Is that too painful?  I think that's 
in keeping with the tradition that unannotated tags are, typically, not 
wanted in a central repository - the default update hook prevents it for 
example.


Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Re: git-fetch and unannotated tags

[Andreas Ericsson]

Andy Parkins wrote:
> 
> I'd be arguing for making not following unannotated tags the default, and then 
> supply a switch to make them followed.  Is that too painful?  I think that's 
> in keeping with the tradition that unannotated tags are, typically, not 
> wanted in a central repository - the default update hook prevents it for 
> example.
> 

Yup. I share your feelings about simple tags. However, unless the repo owner
has decided to explicitly push the simple tag to the repo, or fscked up by
doing "git push --all" when he had cruft in his own repo, those tags are
in fact part of the repo.

In the "oops" case, I'd point this out to the owner so he/she can delete them
from the central repo (and enable the update-hook that barfs when simple tags
are pushed). If the owner actually wants the tags there, then they're
obviously important for some reason, so keeping them might make sense.

If anything, I'd be more interested in teaching git how to clean up simple
tags. That fix is useful on a wider basis and the "simple vs annotated"
recognition code can be useful for skipping unannotated tags when doing
"git push --all --not-simple" (or some such).

I have no idea where to put it though, as I haven't followed git development
very closely as of late.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: git-fetch and unannotated tags

[Jakub Narebski]

Andreas Ericsson wrote:

> Andy Parkins wrote:
>> 
>> I'd be arguing for making not following unannotated tags the default, and then 
>> supply a switch to make them followed.  Is that too painful?  I think that's 
>> in keeping with the tradition that unannotated tags are, typically, not 
>> wanted in a central repository - the default update hook prevents it for 
>> example.
> 
> Yup. I share your feelings about simple tags. However, unless the repo owner
> has decided to explicitly push the simple tag to the repo, or fscked up by
> doing "git push --all" when he had cruft in his own repo, those tags are
> in fact part of the repo.
> 
> In the "oops" case, I'd point this out to the owner so he/she can delete them
> from the central repo (and enable the update-hook that barfs when simple tags
> are pushed). If the owner actually wants the tags there, then they're
> obviously important for some reason, so keeping them might make sense.

You can delete branch (ref?) using "<branch>:" refspec, if server you push to
has git new enough. HTH.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: git-fetch and unannotated tags

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> You can delete branch (ref?) using "<branch>:" refspec, if server you push to
> has git new enough. HTH.

I think you mean

	$ git push $URL :refs/heads/i-do-not-want-this-branch-anymore

that is, colon before existing ref, not after.

[PATCH 0/2] bookmarks (was: Re: git-fetch and unannotated tags)

[Julian Phillips]

On Wed, 25 Apr 2007, Andy Parkins wrote:

> On Wednesday 2007, April 25, Julian Phillips wrote:
>
>> Why not create a directory .git/refs/bm and put things you don't want
>> to make public in there?  You can then use bm/foo etc ...
>
> I could, but then they don't get treated as tags properly in qgit.  I
> still want to list them in git-tag -l

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.

(You can also create a signed private tag, and then make it public at a 
later date - e.g. maybe a security fix that you have to sit on?)

>
>> You could even modify git-tag to create them for you with some
>> appropriate switch ...
>
> Well yes, but that's the answer to everything isn't it?

Not with closed source software ... :(

The first of the following patches just changes do_one_ref so that passing 
a base with strlen(base) > trim is actually worthwhile.  The second adds 
basic support for private tags (bookmarks).

-- 
Julian

 ---
Nothing is but what is not.

[PATCH 1/2] refs.c: change do_one_ref to not discard any of base

[Julian Phillips]

do_one_ref only compared trim characters of base with the actual ref
name, which basically meant that passing in more than trim characters
in base was pointless.  So use prefixcmp instead, so that all of base
is compared.

This allows for_each_ref to trim only part of the string provided as
base (for example).

Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
---
 refs.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/refs.c b/refs.c
index 89876bf..a771975 100644
--- a/refs.c
+++ b/refs.c
@@ -467,7 +467,7 @@ int read_ref(const char *ref, unsigned char *sha1)
 static int do_one_ref(const char *base, each_ref_fn fn, int trim,
 		      void *cb_data, struct ref_list *entry)
 {
-	if (strncmp(base, entry->name, trim))
+	if (prefixcmp(entry->name, base))
 		return 0;
 	if (is_null_sha1(entry->sha1))
 		return 0;
-- 
1.5.1.2

[PATCH 2/2] Add basic support for bookmarks (create/edit/delete/list)

[Julian Phillips]

A bookmark is basically a private tag, you can create/modify/delete
them by using the -b switch to git-tag.  You can also set
tag.alwaysShowBookmarks so that git-tag -l will always show bookmarks
in addition to tags.

(You have to refer to bookmarks as bm/foo rather than foo to keep the
namespace separate from tags.)

Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
---
 Documentation/config.txt        |    4 ++++
 Documentation/git-rev-parse.txt |    3 +++
 Documentation/git-tag.txt       |   10 +++++++---
 builtin-rev-parse.c             |    5 +++++
 git-tag.sh                      |   28 ++++++++++++++++++++--------
 refs.c                          |    5 +++++
 refs.h                          |    1 +
 7 files changed, 45 insertions(+), 11 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index e0aff53..6a11719 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -597,6 +597,10 @@ showbranch.default::
 	The default set of branches for gitlink:git-show-branch[1].
 	See gitlink:git-show-branch[1].
 
+tag.alwaysShowBookmarks::
+	Tag -l always shows bookmarks, even without -b option.
+	See gitlink:git-tag[1].
+
 tar.umask::
 	By default, gitlink:git-tar-tree[1] sets file and directories modes
 	to 0666 or 0777. While this is both useful and acceptable for projects
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index a8bf656..1d74e21 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -73,6 +73,9 @@ OPTIONS
 --tags::
 	Show tag refs found in `$GIT_DIR/refs/tags`.
 
+--bookmarks::
+	Show bookmarks (private tags) found in `$GIT_DIR/refs/bm`.
+
 --remotes::
 	Show tag refs found in `$GIT_DIR/refs/remotes`.
 
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 70235e8..331b741 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -9,13 +9,14 @@ git-tag - Create, list, delete or verify a tag object signed with GPG
 SYNOPSIS
 --------
 [verse]
-'git-tag' [-a | -s | -u <key-id>] [-f | -v] [-m <msg> | -F <file>]  <name> [<head>]
+'git-tag' [-b] [-a | -s | -u <key-id>] [-f | -v] [-m <msg> | -F <file>]  <name> [<head>]
 'git-tag' -d <name>...
-'git-tag' -l [<pattern>]
+'git-tag' [-b] -l [<pattern>]
 
 DESCRIPTION
 -----------
-Adds a 'tag' reference in `.git/refs/tags/`
+Adds a 'tag' reference in `.git/refs/tags/` (unless -b is given, in which case
+the reference is added in `.git/refs/bm/` instead)
 
 Unless `-f` is given, the tag must not yet exist in
 `.git/refs/tags/` directory.
@@ -45,6 +46,9 @@ OPTIONS
 -a::
 	Make an unsigned, annotated tag object
 
+-b::
+	Make a bookmark (private tag) in refs/bm instead a tag in refs/tags.
+
 -s::
 	Make a GPG-signed tag, using the default e-mail address's key
 
diff --git a/builtin-rev-parse.c b/builtin-rev-parse.c
index 37addb2..1c9086c 100644
--- a/builtin-rev-parse.c
+++ b/builtin-rev-parse.c
@@ -50,6 +50,7 @@ static int is_rev_argument(const char *arg)
 		"--remotes",
 		"--sparse",
 		"--tags",
+		"--bookmarks",
 		"--topo-order",
 		"--date-order",
 		"--unpacked",
@@ -310,6 +311,10 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
 				for_each_tag_ref(show_reference, NULL);
 				continue;
 			}
+			if (!strcmp(arg, "--bookmarks")) {
+				for_each_bookmark_ref(show_reference, NULL);
+				continue;
+			}
 			if (!strcmp(arg, "--remotes")) {
 				for_each_remote_ref(show_reference, NULL);
 				continue;
diff --git a/git-tag.sh b/git-tag.sh
index 4a0a7b6..e42e015 100755
--- a/git-tag.sh
+++ b/git-tag.sh
@@ -1,10 +1,18 @@
 #!/bin/sh
 # Copyright (c) 2005 Linus Torvalds
 
-USAGE='-l [<pattern>] | [-a | -s | -u <key-id>] [-f | -d | -v] [-m <msg>] <tagname> [<head>]'
+USAGE='[-b] -l [<pattern>] | [-b] [-a | -s | -u <key-id>] [-f | -d | -v] [-m <msg>] <tagname> [<head>]'
 SUBDIRECTORY_OK='Yes'
 . git-sh-setup
 
+tag_dir="refs/tags"
+
+bm=
+if git-config --get tag.alwaysShowBookmarks > /dev/null
+then
+	bm=--bookmarks
+fi
+
 message_given=
 annotate=
 signed=
@@ -19,6 +27,10 @@ do
     -a)
 	annotate=1
 	;;
+    -b)
+	bm="--bookmarks"
+	tag_dir="refs/bm"
+	;;
     -s)
 	annotate=1
 	signed=1
@@ -32,7 +44,7 @@ do
 		set x . ;;
 	esac
 	shift
-	git rev-parse --symbolic --tags | sort | grep "$@"
+	git rev-parse --symbolic $bm --tags | sort | grep "$@"
 	exit $?
 	;;
     -m)
@@ -66,12 +78,12 @@ do
 	had_error=0
 	for tag
 	do
-		cur=$(git-show-ref --verify --hash -- "refs/tags/$tag") || {
+		cur=$(git-show-ref --verify --hash -- "$tag_dir/$tag") || {
 			echo >&2 "Seriously, what tag are you talking about?"
 			had_error=1
 			continue
 		}
-		git-update-ref -m 'tag: delete' -d "refs/tags/$tag" "$cur" || {
+		git-update-ref -m 'tag: delete' -d "$tag_dir/$tag" "$cur" || {
 			had_error=1
 			continue
 		}
@@ -82,7 +94,7 @@ do
     -v)
 	shift
 	tag_name="$1"
-	tag=$(git-show-ref --verify --hash -- "refs/tags/$tag_name") ||
+	tag=$(git-show-ref --verify --hash -- "$tag_dir/$tag_name") ||
 		die "Seriously, what tag are you talking about?"
 	git-verify-tag -v "$tag"
 	exit $?
@@ -100,10 +112,10 @@ done
 name="$1"
 [ "$name" ] || usage
 prev=0000000000000000000000000000000000000000
-if git-show-ref --verify --quiet -- "refs/tags/$name"
+if git-show-ref --verify --quiet -- "$tag_dir/$name"
 then
     test -n "$force" || die "tag '$name' already exists"
-    prev=`git rev-parse "refs/tags/$name"`
+    prev=`git rev-parse "$tag_dir/$name"`
 fi
 shift
 git-check-ref-format "tags/$name" ||
@@ -149,5 +161,5 @@ if [ "$annotate" ]; then
     object=$(git-mktag < "$GIT_DIR"/TAG_TMP)
 fi
 
-git update-ref "refs/tags/$name" "$object" "$prev"
+git update-ref "$tag_dir/$name" "$object" "$prev"
 
diff --git a/refs.c b/refs.c
index a771975..b89c946 100644
--- a/refs.c
+++ b/refs.c
@@ -569,6 +569,11 @@ int for_each_tag_ref(each_ref_fn fn, void *cb_data)
 	return do_for_each_ref("refs/tags/", fn, 10, cb_data);
 }
 
+int for_each_bookmark_ref(each_ref_fn fn, void *cb_data)
+{
+	return do_for_each_ref("refs/bm/", fn, 5, cb_data);
+}
+
 int for_each_branch_ref(each_ref_fn fn, void *cb_data)
 {
 	return do_for_each_ref("refs/heads/", fn, 11, cb_data);
diff --git a/refs.h b/refs.h
index f61f6d9..60a15a2 100644
--- a/refs.h
+++ b/refs.h
@@ -21,6 +21,7 @@ typedef int each_ref_fn(const char *refname, const unsigned char *sha1, int flag
 extern int head_ref(each_ref_fn, void *);
 extern int for_each_ref(each_ref_fn, void *);
 extern int for_each_tag_ref(each_ref_fn, void *);
+extern int for_each_bookmark_ref(each_ref_fn, void *);
 extern int for_each_branch_ref(each_ref_fn, void *);
 extern int for_each_remote_ref(each_ref_fn, void *);
 
-- 
1.5.1.2

Re: [PATCH 2/2] Add basic support for bookmarks (create/edit/delete/list)

[A Large Angry SCM]

Julian Phillips wrote:
> A bookmark is basically a private tag, you can create/modify/delete
> them by using the -b switch to git-tag.  You can also set
> tag.alwaysShowBookmarks so that git-tag -l will always show bookmarks
> in addition to tags.
> 
> (You have to refer to bookmarks as bm/foo rather than foo to keep the
> namespace separate from tags.)
> 

Can we please use a more descriptive namespace name than 'bm'?

Re: [PATCH 2/2] Add basic support for bookmarks (create/edit/delete/list)

[Jeffrey C. Ollie]

[-- Attachment #1: Type: text/plain, Size: 262 bytes --]

On Wed, 2007-04-25 at 20:17 -0400, A Large Angry SCM wrote:
> 
> Can we please use a more descriptive namespace name than 'bm'?

For some people with active imaginations 'bm' might be too
descriptive :).  (Sorry for the OT, but I couldn't resist).

Jeff

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 0/2] bookmarks

[Junio C Hamano]

Julian Phillips <julian@quantumfyre.co.uk> 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]".

Re: [PATCH 0/2] bookmarks

[Julian Phillips]

On Wed, 25 Apr 2007, Junio C Hamano wrote:

> Julian Phillips <julian@quantumfyre.co.uk> 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).

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.

Re: [PATCH 0/2] bookmarks

[Junio C Hamano]

Julian Phillips <julian@quantumfyre.co.uk> 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.

> 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.

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.

> 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.

Re: [PATCH 0/2] bookmarks

[Julian Phillips]

On Thu, 26 Apr 2007, Junio C Hamano wrote:

> Julian Phillips <julian@quantumfyre.co.uk> 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

Re: [PATCH 0/2] bookmarks

[Andy Parkins]

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

Re: [PATCH 0/2] bookmarks

[Andy Parkins]

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

Re: [PATCH 0/2] bookmarks

[Petr Baudis]

On Thu, Apr 26, 2007 at 10:33:36AM CEST, Andy Parkins wrote:
> 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 :-)

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

Re: [PATCH 0/2] bookmarks (was: Re: git-fetch and unannotated tags)

[Andy Parkins]

On Wednesday 2007 April 25, Julian Phillips wrote:

> 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.

The problem I have with this is that in my mind lightweight tags /are/ 
bookmarks - why create another namespace for them with all the extra code 
that is needed to deal with them?  If we implemented this bookmark stuff then 
I can't envisage ever using a lightweight tag.

Maybe I'm missing the point - what do people see lightweight tags as useful 
for if not for marking revisions in a not-to-be-published fashion?



Andy

-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Re: [PATCH 0/2] bookmarks (was: Re: git-fetch and unannotated tags)

[Julian Phillips]

On Thu, 26 Apr 2007, Andy Parkins wrote:

> On Wednesday 2007 April 25, Julian Phillips wrote:
>
>> 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.
>
> The problem I have with this is that in my mind lightweight tags /are/
> bookmarks - why create another namespace for them with all the extra code
> that is needed to deal with them?  If we implemented this bookmark stuff then
> I can't envisage ever using a lightweight tag.

Well, I was thinking more about having private full tags ... but I think 
the tagopt thing you mentioned later already covers it.

>
> Maybe I'm missing the point - what do people see lightweight tags as useful
> for if not for marking revisions in a not-to-be-published fashion?

I use them in private projects 'cos I'm lazy - but that's not really 
relevant ...

-- 
Julian

  ---
Lewis's Law of Travel:
 	The first piece of luggage out of the chute doesn't belong to anyone,
 	ever.

Re: [PATCH 0/2] bookmarks (was: Re: git-fetch and unannotated tags)

[Karl Hasselström]

On 2007-04-26 09:08:06 +0100, Andy Parkins wrote:

> Maybe I'm missing the point - what do people see lightweight tags as
> useful for if not for marking revisions in a not-to-be-published
> fashion?

I agree. Lightweight tags intentionally lack all the information that
heavyweight tags have: committer/author, date, and log message. This
makes them quick and handy as a personal bookmarking system, but less
friendly for communication with others: all you have is the name. You
can't even know who created the tag, or when, or for what purpose,
unless it's all encoded it the tag name.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: [PATCH 0/2] bookmarks (was: Re: git-fetch and unannotated tags)

[Linus Torvalds]

On Thu, 26 Apr 2007, Andy Parkins wrote:
> 
> Maybe I'm missing the point - what do people see lightweight tags as useful 
> for if not for marking revisions in a not-to-be-published fashion?

I think that's unquestionably _one_ valid way to use them, but I don't 
think it's at all necessarily the only way.

It's equally valid to just always use lightweight tags for everything. 
If you don't use the signing capability, the "real tags" (ie with a tag 
object) don't really buy you much anything at all apart from the message 
(which few enough people fill with anything relevant anyway), so why use 
them?

And yes, signing things is certainly a good idea for releases, but there's 
not really any reason to do it if you're using the tag to just communicate 
with other people (aka "look, here is the thing I want you to merge") 
inside a company or group.

So publishing lightweight tags makes perfect sense in that situation. I 
think it's probably a nicer idea to have some way to specify "don't 
publish" either per-remote or just generally (ie have a rule something 
like "refs/tags/local/" are not pushed or pulled unless explicitly asked 
for).

		Linus