{"thread":{"id":"7842","subject":"git-fetch and unannotated tags","startedAt":"2007-04-25T19:04:42Z","lastAt":"2007-04-29T06:44:48Z","messageCount":24,"participants":["Andy Parkins","Julian Phillips","Junio C Hamano","A Large Angry SCM","Jeffrey C. Ollie","Karl Hasselström","Andreas Ericsson","Linus Torvalds","Petr Baudis","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"40422","messageId":"200704252004.45112.andyparkins@gmail.com","threadId":"7842","inReplyTo":null,"subject":"git-fetch and unannotated tags","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-04-25T19:04:42Z","receivedAt":"2007-04-25T19:04:42Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"Hello,\n\nI often use unannotated tags to mark particular revisions in a \nrepository.  I use unannotated tags just as I would a bookmark.  \nAnnotated tags I reserve for information about a particular revision \nthat I want to share with the world.  In essence I treat unannotated \ntags as private and annotated tags as public.\n\nUnfortunately, git doesn't help me with this.  When I fetch from a \nrepository that has unannotated tags, those tags are transferred.\n\nIs there any way to stop this?  I'm fine with git doing automatic \ntransfer of annotated tags, but not the unannotated.  The only way I \ncan get around this is to use branches instead, that way whether they \nare transferred or not is completely under my control.\n\nThat makes me think that perhaps we should remove the special treatment \nof tags and treat them just like any other ref...\n\n[remote \"origin\"]\n  url = whatever\n  fetch = refs/tags/*:refs/tags/*\n\nHowever that still doesn't distinguish between annotated and \nunannotated.  Maybe two different glob tokens?\n\n[remote \"origin\"]\n  url = whatever\n  fetch = refs/tags/?:refs/tags/?\n\nWould mean annotated tags only...\n\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"40433","messageId":"Pine.LNX.4.64.0704252056210.1005@reaper.quantumfyre.co.uk","threadId":"7842","inReplyTo":"200704252004.45112.andyparkins@gmail.com","subject":"Re: git-fetch and unannotated tags","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-04-25T19:59:07Z","receivedAt":"2007-04-25T19:59:07Z","isPatch":false,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Wed, 25 Apr 2007, Andy Parkins wrote:\n\n> Hello,\n>\n> I often use unannotated tags to mark particular revisions in a\n> repository.  I use unannotated tags just as I would a bookmark.\n> Annotated tags I reserve for information about a particular revision\n> that I want to share with the world.  In essence I treat unannotated\n> tags as private and annotated tags as public.\n\nWhy not create a directory .git/refs/bm and put things you don't want to \nmake public in there?  You can then use bm/foo etc ...\n\nYou could even modify git-tag to create them for you with some appropriate \nswitch ...\n\n-- \nJulian\n\n  ---\nFirst Rule of History:\n \tHistory doesn't repeat itself -- historians merely repeat each other.\n"},{"id":"40448","messageId":"200704252142.33756.andyparkins@gmail.com","threadId":"7842","inReplyTo":"Pine.LNX.4.64.0704252056210.1005@reaper.quantumfyre.co.uk","subject":"Re: git-fetch and unannotated tags","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-04-25T20:42:32Z","receivedAt":"2007-04-25T20:42:32Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2007, April 25, Julian Phillips wrote:\n\n> Why not create a directory .git/refs/bm and put things you don't want\n> to make public in there?  You can then use bm/foo etc ...\n\nI could, but then they don't get treated as tags properly in qgit.  I \nstill want to list them in git-tag -l\n\n> You could even modify git-tag to create them for you with some\n> appropriate switch ...\n\nWell yes, but that's the answer to everything isn't it?\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"40453","messageId":"7vfy6ow4my.fsf@assigned-by-dhcp.cox.net","threadId":"7842","inReplyTo":"200704252142.33756.andyparkins@gmail.com","subject":"Re: git-fetch and unannotated tags","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-25T21:00:53Z","receivedAt":"2007-04-25T21:00:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins <andyparkins@gmail.com> writes:\n\n>> You could even modify git-tag to create them for you with some\n>> appropriate switch ...\n>\n> Well yes, but that's the answer to everything isn't it?\n\nThe answer to everything you want to change the current\nbehaviour is to code something that implement that change.  What\nelse is new?\n\nI suspect that if you look at what git-fetch.sh does in the\nparagraph that follows /^# automated tag following/, it probably\nis not that much change.  At that point,\n\n (1) $ls_remote_result contains the output from \"git ls-remote $URL\"\n     we ran earlier, LF and everything intact.\n\n (2) show-ref --exclude-existing=refs/tags/ discards, out of\n     $ls_remote_result, everything that does not begin with refs/tags/,\n     and at the same time, discards the ones you already have.\n     This is done after stripping away ^{} markers.\n\n (3) The remainder is fed to the while loop, which says \"if we\n     already have the object pointed at by a surviving ref under\n     refs/tags/ in the remote, follow that tag\".\n\nSo I think you could filter out the ones that do not have\ncorresponding ^{} in $ls_remote_result from the while loop.  As\nthe use of \"show-ref --exclude-existing\" is to speed things up\nby reducing the work done in the while loop written in shell, I\nwould suggest giving another option to show-ref that can be used\ntogether with --exclude-existing.\n\nTake a look at exclude_existing() function in builtin-show-ref.c;\nyour additional option to the command would say something like:\n\n  - ignore everything that do not begin with match (as we do now\n    already);\n\n  - if we do not have the ref we read from the stdin (determined\n    with the call to path_list_has_path() there), instead of\n    running printf() unconditionally as we do now, make sure we\n    have both refs/tags/foo and refs/tags/foo^{} in the input.\n    And show only those.\n"},{"id":"40466","messageId":"20070425225021.15383.87006.julian@quantumfyre.co.uk","threadId":"7842","inReplyTo":"Pine.LNX.4.64.0704252332170.18446@beast.quantumfyre.co.uk","subject":"[PATCH 1/2] refs.c: change do_one_ref to not discard any of base","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-04-25T22:25:10Z","receivedAt":"2007-04-25T22:25:10Z","isPatch":true,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"do_one_ref only compared trim characters of base with the actual ref\nname, which basically meant that passing in more than trim characters\nin base was pointless.  So use prefixcmp instead, so that all of base\nis compared.\n\nThis allows for_each_ref to trim only part of the string provided as\nbase (for example).\n\nSigned-off-by: Julian Phillips <julian@quantumfyre.co.uk>\n---\n refs.c |    2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/refs.c b/refs.c\nindex 89876bf..a771975 100644\n--- a/refs.c\n+++ b/refs.c\n@@ -467,7 +467,7 @@ int read_ref(const char *ref, unsigned char *sha1)\n static int do_one_ref(const char *base, each_ref_fn fn, int trim,\n \t\t      void *cb_data, struct ref_list *entry)\n {\n-\tif (strncmp(base, entry->name, trim))\n+\tif (prefixcmp(entry->name, base))\n \t\treturn 0;\n \tif (is_null_sha1(entry->sha1))\n \t\treturn 0;\n-- \n1.5.1.2\n"},{"id":"40468","messageId":"20070425225021.15383.4504.julian@quantumfyre.co.uk","threadId":"7842","inReplyTo":"20070425225021.15383.87006.julian@quantumfyre.co.uk","subject":"[PATCH 2/2] Add basic support for bookmarks (create/edit/delete/list)","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-04-25T22:29:42Z","receivedAt":"2007-04-25T22:29:42Z","isPatch":true,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"A bookmark is basically a private tag, you can create/modify/delete\nthem by using the -b switch to git-tag.  You can also set\ntag.alwaysShowBookmarks so that git-tag -l will always show bookmarks\nin addition to tags.\n\n(You have to refer to bookmarks as bm/foo rather than foo to keep the\nnamespace separate from tags.)\n\nSigned-off-by: Julian Phillips <julian@quantumfyre.co.uk>\n---\n Documentation/config.txt        |    4 ++++\n Documentation/git-rev-parse.txt |    3 +++\n Documentation/git-tag.txt       |   10 +++++++---\n builtin-rev-parse.c             |    5 +++++\n git-tag.sh                      |   28 ++++++++++++++++++++--------\n refs.c                          |    5 +++++\n refs.h                          |    1 +\n 7 files changed, 45 insertions(+), 11 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex e0aff53..6a11719 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -597,6 +597,10 @@ showbranch.default::\n \tThe default set of branches for gitlink:git-show-branch[1].\n \tSee gitlink:git-show-branch[1].\n \n+tag.alwaysShowBookmarks::\n+\tTag -l always shows bookmarks, even without -b option.\n+\tSee gitlink:git-tag[1].\n+\n tar.umask::\n \tBy default, gitlink:git-tar-tree[1] sets file and directories modes\n \tto 0666 or 0777. While this is both useful and acceptable for projects\ndiff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt\nindex a8bf656..1d74e21 100644\n--- a/Documentation/git-rev-parse.txt\n+++ b/Documentation/git-rev-parse.txt\n@@ -73,6 +73,9 @@ OPTIONS\n --tags::\n \tShow tag refs found in `$GIT_DIR/refs/tags`.\n \n+--bookmarks::\n+\tShow bookmarks (private tags) found in `$GIT_DIR/refs/bm`.\n+\n --remotes::\n \tShow tag refs found in `$GIT_DIR/refs/remotes`.\n \ndiff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt\nindex 70235e8..331b741 100644\n--- a/Documentation/git-tag.txt\n+++ b/Documentation/git-tag.txt\n@@ -9,13 +9,14 @@ git-tag - Create, list, delete or verify a tag object signed with GPG\n SYNOPSIS\n --------\n [verse]\n-'git-tag' [-a | -s | -u <key-id>] [-f | -v] [-m <msg> | -F <file>]  <name> [<head>]\n+'git-tag' [-b] [-a | -s | -u <key-id>] [-f | -v] [-m <msg> | -F <file>]  <name> [<head>]\n 'git-tag' -d <name>...\n-'git-tag' -l [<pattern>]\n+'git-tag' [-b] -l [<pattern>]\n \n DESCRIPTION\n -----------\n-Adds a 'tag' reference in `.git/refs/tags/`\n+Adds a 'tag' reference in `.git/refs/tags/` (unless -b is given, in which case\n+the reference is added in `.git/refs/bm/` instead)\n \n Unless `-f` is given, the tag must not yet exist in\n `.git/refs/tags/` directory.\n@@ -45,6 +46,9 @@ OPTIONS\n -a::\n \tMake an unsigned, annotated tag object\n \n+-b::\n+\tMake a bookmark (private tag) in refs/bm instead a tag in refs/tags.\n+\n -s::\n \tMake a GPG-signed tag, using the default e-mail address's key\n \ndiff --git a/builtin-rev-parse.c b/builtin-rev-parse.c\nindex 37addb2..1c9086c 100644\n--- a/builtin-rev-parse.c\n+++ b/builtin-rev-parse.c\n@@ -50,6 +50,7 @@ static int is_rev_argument(const char *arg)\n \t\t\"--remotes\",\n \t\t\"--sparse\",\n \t\t\"--tags\",\n+\t\t\"--bookmarks\",\n \t\t\"--topo-order\",\n \t\t\"--date-order\",\n \t\t\"--unpacked\",\n@@ -310,6 +311,10 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)\n \t\t\t\tfor_each_tag_ref(show_reference, NULL);\n \t\t\t\tcontinue;\n \t\t\t}\n+\t\t\tif (!strcmp(arg, \"--bookmarks\")) {\n+\t\t\t\tfor_each_bookmark_ref(show_reference, NULL);\n+\t\t\t\tcontinue;\n+\t\t\t}\n \t\t\tif (!strcmp(arg, \"--remotes\")) {\n \t\t\t\tfor_each_remote_ref(show_reference, NULL);\n \t\t\t\tcontinue;\ndiff --git a/git-tag.sh b/git-tag.sh\nindex 4a0a7b6..e42e015 100755\n--- a/git-tag.sh\n+++ b/git-tag.sh\n@@ -1,10 +1,18 @@\n #!/bin/sh\n # Copyright (c) 2005 Linus Torvalds\n \n-USAGE='-l [<pattern>] | [-a | -s | -u <key-id>] [-f | -d | -v] [-m <msg>] <tagname> [<head>]'\n+USAGE='[-b] -l [<pattern>] | [-b] [-a | -s | -u <key-id>] [-f | -d | -v] [-m <msg>] <tagname> [<head>]'\n SUBDIRECTORY_OK='Yes'\n . git-sh-setup\n \n+tag_dir=\"refs/tags\"\n+\n+bm=\n+if git-config --get tag.alwaysShowBookmarks > /dev/null\n+then\n+\tbm=--bookmarks\n+fi\n+\n message_given=\n annotate=\n signed=\n@@ -19,6 +27,10 @@ do\n     -a)\n \tannotate=1\n \t;;\n+    -b)\n+\tbm=\"--bookmarks\"\n+\ttag_dir=\"refs/bm\"\n+\t;;\n     -s)\n \tannotate=1\n \tsigned=1\n@@ -32,7 +44,7 @@ do\n \t\tset x . ;;\n \tesac\n \tshift\n-\tgit rev-parse --symbolic --tags | sort | grep \"$@\"\n+\tgit rev-parse --symbolic $bm --tags | sort | grep \"$@\"\n \texit $?\n \t;;\n     -m)\n@@ -66,12 +78,12 @@ do\n \thad_error=0\n \tfor tag\n \tdo\n-\t\tcur=$(git-show-ref --verify --hash -- \"refs/tags/$tag\") || {\n+\t\tcur=$(git-show-ref --verify --hash -- \"$tag_dir/$tag\") || {\n \t\t\techo >&2 \"Seriously, what tag are you talking about?\"\n \t\t\thad_error=1\n \t\t\tcontinue\n \t\t}\n-\t\tgit-update-ref -m 'tag: delete' -d \"refs/tags/$tag\" \"$cur\" || {\n+\t\tgit-update-ref -m 'tag: delete' -d \"$tag_dir/$tag\" \"$cur\" || {\n \t\t\thad_error=1\n \t\t\tcontinue\n \t\t}\n@@ -82,7 +94,7 @@ do\n     -v)\n \tshift\n \ttag_name=\"$1\"\n-\ttag=$(git-show-ref --verify --hash -- \"refs/tags/$tag_name\") ||\n+\ttag=$(git-show-ref --verify --hash -- \"$tag_dir/$tag_name\") ||\n \t\tdie \"Seriously, what tag are you talking about?\"\n \tgit-verify-tag -v \"$tag\"\n \texit $?\n@@ -100,10 +112,10 @@ done\n name=\"$1\"\n [ \"$name\" ] || usage\n prev=0000000000000000000000000000000000000000\n-if git-show-ref --verify --quiet -- \"refs/tags/$name\"\n+if git-show-ref --verify --quiet -- \"$tag_dir/$name\"\n then\n     test -n \"$force\" || die \"tag '$name' already exists\"\n-    prev=`git rev-parse \"refs/tags/$name\"`\n+    prev=`git rev-parse \"$tag_dir/$name\"`\n fi\n shift\n git-check-ref-format \"tags/$name\" ||\n@@ -149,5 +161,5 @@ if [ \"$annotate\" ]; then\n     object=$(git-mktag < \"$GIT_DIR\"/TAG_TMP)\n fi\n \n-git update-ref \"refs/tags/$name\" \"$object\" \"$prev\"\n+git update-ref \"$tag_dir/$name\" \"$object\" \"$prev\"\n \ndiff --git a/refs.c b/refs.c\nindex a771975..b89c946 100644\n--- a/refs.c\n+++ b/refs.c\n@@ -569,6 +569,11 @@ int for_each_tag_ref(each_ref_fn fn, void *cb_data)\n \treturn do_for_each_ref(\"refs/tags/\", fn, 10, cb_data);\n }\n \n+int for_each_bookmark_ref(each_ref_fn fn, void *cb_data)\n+{\n+\treturn do_for_each_ref(\"refs/bm/\", fn, 5, cb_data);\n+}\n+\n int for_each_branch_ref(each_ref_fn fn, void *cb_data)\n {\n \treturn do_for_each_ref(\"refs/heads/\", fn, 11, cb_data);\ndiff --git a/refs.h b/refs.h\nindex f61f6d9..60a15a2 100644\n--- a/refs.h\n+++ b/refs.h\n@@ -21,6 +21,7 @@ typedef int each_ref_fn(const char *refname, const unsigned char *sha1, int flag\n extern int head_ref(each_ref_fn, void *);\n extern int for_each_ref(each_ref_fn, void *);\n extern int for_each_tag_ref(each_ref_fn, void *);\n+extern int for_each_bookmark_ref(each_ref_fn, void *);\n extern int for_each_branch_ref(each_ref_fn, void *);\n extern int for_each_remote_ref(each_ref_fn, void *);\n \n-- \n1.5.1.2\n"},{"id":"40467","messageId":"Pine.LNX.4.64.0704252332170.18446@beast.quantumfyre.co.uk","threadId":"7842","inReplyTo":"200704252142.33756.andyparkins@gmail.com","subject":"[PATCH 0/2] bookmarks (was: Re: git-fetch and unannotated tags)","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-04-25T22:51:27Z","receivedAt":"2007-04-25T22:51:27Z","isPatch":true,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Wed, 25 Apr 2007, Andy Parkins wrote:\n\n> On Wednesday 2007, April 25, Julian Phillips wrote:\n>\n>> Why not create a directory .git/refs/bm and put things you don't want\n>> to make public in there?  You can then use bm/foo etc ...\n>\n> I could, but then they don't get treated as tags properly in qgit.  I\n> still want to list them in git-tag -l\n\nWhile I like the idea of private tags, I find the idea of them having \ntheir own namespace to be much more attractive than simply having the \nability to not export lightweight tags.\n\nIn particular it means that you can control which tags are exported \nindividually.\n\n(You can also create a signed private tag, and then make it public at a \nlater date - e.g. maybe a security fix that you have to sit on?)\n\n>\n>> You could even modify git-tag to create them for you with some\n>> appropriate switch ...\n>\n> Well yes, but that's the answer to everything isn't it?\n\nNot with closed source software ... :(\n\nThe first of the following patches just changes do_one_ref so that passing \na base with strlen(base) > trim is actually worthwhile.  The second adds \nbasic support for private tags (bookmarks).\n\n-- \nJulian\n\n ---\nNothing is but what is not.\n"},{"id":"40471","messageId":"462FEF94.7040409@gmail.com","threadId":"7842","inReplyTo":"20070425225021.15383.4504.julian@quantumfyre.co.uk","subject":"Re: [PATCH 2/2] Add basic support for bookmarks (create/edit/delete/list)","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2007-04-26T00:17:24Z","receivedAt":"2007-04-26T00:17:24Z","isPatch":true,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Julian Phillips wrote:\n> A bookmark is basically a private tag, you can create/modify/delete\n> them by using the -b switch to git-tag.  You can also set\n> tag.alwaysShowBookmarks so that git-tag -l will always show bookmarks\n> in addition to tags.\n> \n> (You have to refer to bookmarks as bm/foo rather than foo to keep the\n> namespace separate from tags.)\n> \n\nCan we please use a more descriptive namespace name than 'bm'?\n"},{"id":"40472","messageId":"1177547368.4109.9.camel@lt21223.campus.dmacc.edu","threadId":"7842","inReplyTo":"462FEF94.7040409@gmail.com","subject":"Re: [PATCH 2/2] Add basic support for bookmarks (create/edit/delete/list)","fromName":"Jeffrey C. Ollie","fromEmail":"jeff@ocjtech.us","sentAt":"2007-04-26T00:29:28Z","receivedAt":"2007-04-26T00:29:28Z","isPatch":true,"sender":{"key":"jeff@ocjtech.us","avatar":"https://gravatar.com/avatar/95918a1992f277a811c471ae7275f7e4c9d1a2e517ad290bd6aa93b97e8d34f3?d=mp&s=160"},"body":"On Wed, 2007-04-25 at 20:17 -0400, A Large Angry SCM wrote:\n> \n> Can we please use a more descriptive namespace name than 'bm'?\n\nFor some people with active imaginations 'bm' might be too\ndescriptive :).  (Sorry for the OT, but I couldn't resist).\n\nJeff\n"},{"id":"40489","messageId":"7vmz0vu1fc.fsf@assigned-by-dhcp.cox.net","threadId":"7842","inReplyTo":"Pine.LNX.4.64.0704252332170.18446@beast.quantumfyre.co.uk","subject":"Re: [PATCH 0/2] bookmarks","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-26T05:53:11Z","receivedAt":"2007-04-26T05:53:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Julian Phillips <julian@quantumfyre.co.uk> writes:\n\n> While I like the idea of private tags, I find the idea of them having \n> their own namespace to be much more attractive than simply having the \n> ability to not export lightweight tags.\n>\n> In particular it means that you can control which tags are exported \n> individually.\n\nI do not think this is limited to tags. Sometimes you may want\nto make some branches private.  It probably is also a good idea\nto hide StGIT patch base refs that live under $GIT_DIR/refs/.\n\nHere, I do not use the word \"private\" in the sense of being\n\"secret\", as most likely branches that share common root would\nhave many trees and blobs in common, but in the sense of \"less\nclutter\".\n\nHow would one find out about remote refs?  By running\nls-remote.  And that happens to also be how git-fetch follows\ntags (the original issue Andy had).\n\nOver native git protocol, upload-pack is the program that runs\nin the repote repository and gives list of available refs and\nobject names they point at (upload-pack.c::send_ref()).  To dumb\nclients, update-server-info creates the equivalent information\nin $GIT_DIR/info/refs and that is what the ls-remote sees.\n\nSo I suspect that a more general solution would be to to teach\nthese two programs to take notice of a new configuration\nvariable you can set in the repository to limit the set of refs\nto give out.  Then you do not have to introduce a new namespace,\n\nProbably the configuration would be a glob pattern (for pathname\nlike things, we tend to use shell glob, not regexp) to\ninclude/exclude.  E.g.\n\n\trefs.expose = refs/heads/*\n        refs.expose = refs/tags/*\n        refs.expose = !refs/heads/*/*\n        refs.expose = !refs/tags/v[0-9]*\n\nwould let you say \"I would want to expose all of refs/heads/\n(i.e. branches) and refs/tags (i.e. tags), but I do not want to\nshow branches with '/' in their names, nor tags whose names do\nnot begin with v[0-9]\".\n"},{"id":"40492","messageId":"Pine.LNX.4.64.0704260816480.27356@beast.quantumfyre.co.uk","threadId":"7842","inReplyTo":"7vmz0vu1fc.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] bookmarks","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-04-26T07:25:13Z","receivedAt":"2007-04-26T07:25:13Z","isPatch":true,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Wed, 25 Apr 2007, Junio C Hamano wrote:\n\n> Julian Phillips <julian@quantumfyre.co.uk> writes:\n>\n>> While I like the idea of private tags, I find the idea of them having\n>> their own namespace to be much more attractive than simply having the\n>> ability to not export lightweight tags.\n>>\n>> In particular it means that you can control which tags are exported\n>> individually.\n>\n> I do not think this is limited to tags. Sometimes you may want\n> to make some branches private.  It probably is also a good idea\n> to hide StGIT patch base refs that live under $GIT_DIR/refs/.\n>\n> Here, I do not use the word \"private\" in the sense of being\n> \"secret\", as most likely branches that share common root would\n> have many trees and blobs in common, but in the sense of \"less\n> clutter\".\n>\n> How would one find out about remote refs?  By running\n> ls-remote.  And that happens to also be how git-fetch follows\n> tags (the original issue Andy had).\n\nSurely though, what you really want is to simply not put the private refs \ninto a public repo.  So the thing to be controlling is push, not fetch.\n\nThat way you are not reliant on the user's tools following your rules.\n\nI don't think it unreasonable to say that anything that is in a public \nrepository is public, and that the way to keep things private is to not \npush them into a public repository. Or is it?\n\nI understand that some people may wish to make their working repositories \npublic, but then there isn't any way we can say for sure that things will \nremain private.  Even if ls-remote was updated, an older version would \nsimply ignore the new \"this is private\" configuration.\n\n>\n> Over native git protocol, upload-pack is the program that runs\n> in the repote repository and gives list of available refs and\n> object names they point at (upload-pack.c::send_ref()).  To dumb\n> clients, update-server-info creates the equivalent information\n> in $GIT_DIR/info/refs and that is what the ls-remote sees.\n>\n> So I suspect that a more general solution would be to to teach\n> these two programs to take notice of a new configuration\n> variable you can set in the repository to limit the set of refs\n> to give out.  Then you do not have to introduce a new namespace,\n>\n> Probably the configuration would be a glob pattern (for pathname\n> like things, we tend to use shell glob, not regexp) to\n> include/exclude.  E.g.\n>\n> \trefs.expose = refs/heads/*\n>        refs.expose = refs/tags/*\n>        refs.expose = !refs/heads/*/*\n>        refs.expose = !refs/tags/v[0-9]*\n>\n> would let you say \"I would want to expose all of refs/heads/\n> (i.e. branches) and refs/tags (i.e. tags), but I do not want to\n> show branches with '/' in their names, nor tags whose names do\n> not begin with v[0-9]\".\n\nor simply expand the current push configuration to accept that syntax, so \nthat you can finely control which refs get pushed to the public repo?\n\n-- \nJulian\n\n  ---\nOnly two of my personalities are schizophrenic, but one of them is\nparanoid and the other one is out to get him.\n"},{"id":"40493","messageId":"7v647jtvzb.fsf@assigned-by-dhcp.cox.net","threadId":"7842","inReplyTo":"Pine.LNX.4.64.0704260816480.27356@beast.quantumfyre.co.uk","subject":"Re: [PATCH 0/2] bookmarks","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-26T07:50:48Z","receivedAt":"2007-04-26T07:50:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Julian Phillips <julian@quantumfyre.co.uk> writes:\n\n> That way you are not reliant on the user's tools following your rules.\n\nYou misunderstood -- what implements the rules is on the\nrepository side, not the end users' side.\n\n> I don't think it unreasonable to say that anything that is in a public\n> repository is public, and that the way to keep things private is to\n> not push them into a public repository. Or is it?\n\nI wouldn't have bothered to jump into the thread if this were\nabout public repositories.  You would not even need a separate\nnamespace refs/bm -- you do not have to push that out.\n\nBut that was not what Andy was talking about.\n\n> I understand that some people may wish to make their working\n> repositories public, but then there isn't any way we can say for sure\n> that things will remain private.  Even if ls-remote was updated, an\n> older version would simply ignore the new \"this is private\"\n> configuration.\n\nYou misunderstood.  I am not talking about updating ls-remote.\nThe update to upload-pack/update-server-info is done on the side\nof Andy's repository, not on the client side.\n\n> or simply expand the current push configuration to accept that syntax,\n> so that you can finely control which refs get pushed to the public\n> repo?\n\nYou do not have to update anything on push side, as push just\npushes what you tell it to, unless you say 'push --all', in\nwhich case you obviously mean all is all is all, so there is no\nneed for exclude.\n"},{"id":"40494","messageId":"200704260904.08447.andyparkins@gmail.com","threadId":"7842","inReplyTo":"7vfy6ow4my.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-fetch and unannotated tags","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-04-26T08:04:07Z","receivedAt":"2007-04-26T08:04:07Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2007 April 25, Junio C Hamano wrote:\n\n> >> You could even modify git-tag to create them for you with some\n> >> appropriate switch ...\n> >\n> > Well yes, but that's the answer to everything isn't it?\n>\n> The answer to everything you want to change the current\n> behaviour is to code something that implement that change.  What\n> else is new?\n\nApologies - I wasn't saying that someone else should add features I want, I \nwas saying that locally changing /my/ git-tag isn't very useful.  I already \nget by with git, so when I post suggestions to the mailing list it's usually \nwith respect to the wider context.   In this case, patching git-tag to create \nrefs/andys-private-tags/ doesn't seem like the right thing to do in mainline \ngit :-)\n\n> I suspect that if you look at what git-fetch.sh does in the\n> paragraph that follows /^# automated tag following/, it probably\n> is not that much change.  At that point,\n ... snip ...\n\nThat advice on the other hand is excellent.\n\nIs this something that others would be in favour of?  I'm soliciting for \nreasons why unannotated tags should be auto-followed?\n\n> Take a look at exclude_existing() function in builtin-show-ref.c;\n> your additional option to the command would say something like:\n\nI'd be arguing for making not following unannotated tags the default, and then \nsupply a switch to make them followed.  Is that too painful?  I think that's \nin keeping with the tradition that unannotated tags are, typically, not \nwanted in a central repository - the default update hook prevents it for \nexample.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"40495","messageId":"200704260908.07108.andyparkins@gmail.com","threadId":"7842","inReplyTo":"Pine.LNX.4.64.0704252332170.18446@beast.quantumfyre.co.uk","subject":"Re: [PATCH 0/2] bookmarks (was: Re: git-fetch and unannotated tags)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-04-26T08:08:06Z","receivedAt":"2007-04-26T08:08:06Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2007 April 25, Julian Phillips wrote:\n\n> While I like the idea of private tags, I find the idea of them having\n> their own namespace to be much more attractive than simply having the\n> ability to not export lightweight tags.\n\nThe problem I have with this is that in my mind lightweight tags /are/ \nbookmarks - why create another namespace for them with all the extra code \nthat is needed to deal with them?  If we implemented this bookmark stuff then \nI can't envisage ever using a lightweight tag.\n\nMaybe I'm missing the point - what do people see lightweight tags as useful \nfor if not for marking revisions in a not-to-be-published fashion?\n\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"40497","messageId":"200704260923.26637.andyparkins@gmail.com","threadId":"7842","inReplyTo":"Pine.LNX.4.64.0704260816480.27356@beast.quantumfyre.co.uk","subject":"Re: [PATCH 0/2] bookmarks","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-04-26T08:23:25Z","receivedAt":"2007-04-26T08:23:25Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2007 April 26, Julian Phillips wrote:\n\n> > How would one find out about remote refs?  By running\n> > ls-remote.  And that happens to also be how git-fetch follows\n> > tags (the original issue Andy had).\n>\n> Surely though, what you really want is to simply not put the private refs\n> into a public repo.  So the thing to be controlling is push, not fetch.\n\nThat's already taken care of by the update hook.  The default example that \ncomes with git prevents the pushing of unannotated tags, and could be \nmodified to prevent the pushing of any subset of refs that you wanted.\n\nWhat I'm really talking about is the default functionality - we've got the \nglob syntax in the config for controlling which branches get pushed, that \nmakes it easy to make branches that you don't want pushed.  For example you \nmight have\n\n [remote \"origin\"]\n   url = somewhere\n   push = refs/heads/publish/*:refs/heads/*\n   fetch = refs/heads/*:refs/remotes/origin/*\n\nThat way, only branches that I prefix with \"publish/\" get pushed.  All I'm \nafter is a similar facility for tags.  Unfortunately, git assumes that I'm \nalways going to want all tags so there is no namespace divisions I can make.\n\n> I don't think it unreasonable to say that anything that is in a public\n> repository is public, and that the way to keep things private is to not\n> push them into a public repository. Or is it?\n\nI don't think that's unreasonable at all - even though it can be worked around \nusing a hook script, the problem still exists - what if I want the option to \npush a certain tag, but by default I don't want it sent.  For branches it's \nno problem - the [remote] supplies the default and I can always do \n\n git push origin branch\n\nfor the extras.\n\n> I understand that some people may wish to make their working repositories\n> public, but then there isn't any way we can say for sure that things will\n> remain private.  Even if ls-remote was updated, an older version would\n> simply ignore the new \"this is private\" configuration.\n\nNo, no - I certainly don't want to make it public.  That's the point - I want \nto keep all my private things private, and hence I want to be able to control \nwhich branches and which tags are pushed and fetched.\n\n> or simply expand the current push configuration to accept that syntax, so\n> that you can finely control which refs get pushed to the public repo?\n\nYes - exactly right.  That's what I was trying to suggest (badly) with my \n\n[remote \"origin\"]\n  url = whatever\n  fetch = refs/tags/?:refs/tags/?\n\nsuggestion.\n\nTo say it more explicitly - perhaps tags should /not/ be auto-followed, but \nrather treated exactly as branches are?\n\nActually how about this: an option in the remote section to turn off \nauto-following and then add fetch and push lines for the tags too - that \nmeans very minimal changes and then everyone's happy (where everyone = \nme ;-)).\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"40498","messageId":"200704260933.38677.andyparkins@gmail.com","threadId":"7842","inReplyTo":"200704260923.26637.andyparkins@gmail.com","subject":"Re: [PATCH 0/2] bookmarks","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-04-26T08:33:36Z","receivedAt":"2007-04-26T08:33:36Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2007 April 26, Andy Parkins wrote:\n\n> Actually how about this: an option in the remote section to turn off\n> auto-following and then add fetch and push lines for the tags too - that\n> means very minimal changes and then everyone's happy (where everyone =\n> me ;-)).\n\nFunny.  I went looking to add the above facility, and lo-and-behold, it's \nalready there in the form of the remote.$remote.tagopt parameter.\n\n[remote \"origin\"]\n   tagopt = --no-tags\n   push = refs/tags/public:refs/tags/*\n   fetch = refs/tags/*:refs/tags/public/*\n\nThis does exactly what I want.  Once again, git is waaaay ahead of me :-)\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"40499","messageId":"Pine.LNX.4.64.0704260958120.22894@reaper.quantumfyre.co.uk","threadId":"7842","inReplyTo":"200704260908.07108.andyparkins@gmail.com","subject":"Re: [PATCH 0/2] bookmarks (was: Re: git-fetch and unannotated tags)","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-04-26T09:00:17Z","receivedAt":"2007-04-26T09:00:17Z","isPatch":true,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Thu, 26 Apr 2007, Andy Parkins wrote:\n\n> On Wednesday 2007 April 25, Julian Phillips wrote:\n>\n>> While I like the idea of private tags, I find the idea of them having\n>> their own namespace to be much more attractive than simply having the\n>> ability to not export lightweight tags.\n>\n> The problem I have with this is that in my mind lightweight tags /are/\n> bookmarks - why create another namespace for them with all the extra code\n> that is needed to deal with them?  If we implemented this bookmark stuff then\n> I can't envisage ever using a lightweight tag.\n\nWell, I was thinking more about having private full tags ... but I think \nthe tagopt thing you mentioned later already covers it.\n\n>\n> Maybe I'm missing the point - what do people see lightweight tags as useful\n> for if not for marking revisions in a not-to-be-published fashion?\n\nI use them in private projects 'cos I'm lazy - but that's not really \nrelevant ...\n\n-- \nJulian\n\n  ---\nLewis's Law of Travel:\n \tThe first piece of luggage out of the chute doesn't belong to anyone,\n \tever.\n"},{"id":"40501","messageId":"Pine.LNX.4.64.0704260905100.27947@beast.quantumfyre.co.uk","threadId":"7842","inReplyTo":"7v647jtvzb.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] bookmarks","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-04-26T09:04:07Z","receivedAt":"2007-04-26T09:04:07Z","isPatch":true,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Thu, 26 Apr 2007, Junio C Hamano wrote:\n\n> Julian Phillips <julian@quantumfyre.co.uk> writes:\n>\n>> That way you are not reliant on the user's tools following your rules.\n>\n> You misunderstood -- what implements the rules is on the\n> repository side, not the end users' side.\n\nIf your public repo is available via http or rsync, then you can't \nconsider anything private ...\n\nIf it's available via git:// only, then that's different.\n\n>\n>> I don't think it unreasonable to say that anything that is in a public\n>> repository is public, and that the way to keep things private is to\n>> not push them into a public repository. Or is it?\n>\n> I wouldn't have bothered to jump into the thread if this were\n> about public repositories.  You would not even need a separate\n> namespace refs/bm -- you do not have to push that out.\n\nIf the repository is not public, where's the problem?  _Everthing_ is \nprivate then...\n\n(by public I simply mean \"availabe for others to fetch from\")\n\n>\n> But that was not what Andy was talking about.\n>\n>> I understand that some people may wish to make their working\n>> repositories public, but then there isn't any way we can say for sure\n>> that things will remain private.  Even if ls-remote was updated, an\n>> older version would simply ignore the new \"this is private\"\n>> configuration.\n>\n> You misunderstood.  I am not talking about updating ls-remote.\n> The update to upload-pack/update-server-info is done on the side\n> of Andy's repository, not on the client side.\n\nYeah, that's what I get for trying to think before lunch time ... :$\n\n>\n>> or simply expand the current push configuration to accept that syntax,\n>> so that you can finely control which refs get pushed to the public\n>> repo?\n>\n> You do not have to update anything on push side, as push just\n> pushes what you tell it to, unless you say 'push --all', in\n> which case you obviously mean all is all is all, so there is no\n> need for exclude.\n\nHaving thought about after I sent my email, I agree that the current push \nsyntax is already enough.\n\n-- \nJulian\n\n  ---\nBOFH Excuse #56:\n\nElectricians made popcorn in the power supply\n"},{"id":"40512","messageId":"20070426134501.GA3273@diana.vm.bytemark.co.uk","threadId":"7842","inReplyTo":"200704260908.07108.andyparkins@gmail.com","subject":"Re: [PATCH 0/2] bookmarks (was: Re: git-fetch and unannotated tags)","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-04-26T13:45:01Z","receivedAt":"2007-04-26T13:45:01Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-04-26 09:08:06 +0100, Andy Parkins wrote:\n\n> Maybe I'm missing the point - what do people see lightweight tags as\n> useful for if not for marking revisions in a not-to-be-published\n> fashion?\n\nI agree. Lightweight tags intentionally lack all the information that\nheavyweight tags have: committer/author, date, and log message. This\nmakes them quick and handy as a personal bookmarking system, but less\nfriendly for communication with others: all you have is the name. You\ncan't even know who created the tag, or when, or for what purpose,\nunless it's all encoded it the tag name.\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"},{"id":"40515","messageId":"4630C377.8000602@op5.se","threadId":"7842","inReplyTo":"200704260904.08447.andyparkins@gmail.com","subject":"Re: git-fetch and unannotated tags","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-04-26T15:21:27Z","receivedAt":"2007-04-26T15:21:27Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Andy Parkins wrote:\n> \n> I'd be arguing for making not following unannotated tags the default, and then \n> supply a switch to make them followed.  Is that too painful?  I think that's \n> in keeping with the tradition that unannotated tags are, typically, not \n> wanted in a central repository - the default update hook prevents it for \n> example.\n> \n\nYup. I share your feelings about simple tags. However, unless the repo owner\nhas decided to explicitly push the simple tag to the repo, or fscked up by\ndoing \"git push --all\" when he had cruft in his own repo, those tags are\nin fact part of the repo.\n\nIn the \"oops\" case, I'd point this out to the owner so he/she can delete them\nfrom the central repo (and enable the update-hook that barfs when simple tags\nare pushed). If the owner actually wants the tags there, then they're\nobviously important for some reason, so keeping them might make sense.\n\nIf anything, I'd be more interested in teaching git how to clean up simple\ntags. That fix is useful on a wider basis and the \"simple vs annotated\"\nrecognition code can be useful for skipping unannotated tags when doing\n\"git push --all --not-simple\" (or some such).\n\nI have no idea where to put it though, as I haven't followed git development\nvery closely as of late.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"40517","messageId":"alpine.LFD.0.98.0704260915130.9964@woody.linux-foundation.org","threadId":"7842","inReplyTo":"200704260908.07108.andyparkins@gmail.com","subject":"Re: [PATCH 0/2] bookmarks (was: Re: git-fetch and unannotated tags)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-26T16:19:16Z","receivedAt":"2007-04-26T16:19:16Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 26 Apr 2007, Andy Parkins wrote:\n> \n> Maybe I'm missing the point - what do people see lightweight tags as useful \n> for if not for marking revisions in a not-to-be-published fashion?\n\nI think that's unquestionably _one_ valid way to use them, but I don't \nthink it's at all necessarily the only way.\n\nIt's equally valid to just always use lightweight tags for everything. \nIf you don't use the signing capability, the \"real tags\" (ie with a tag \nobject) don't really buy you much anything at all apart from the message \n(which few enough people fill with anything relevant anyway), so why use \nthem?\n\nAnd yes, signing things is certainly a good idea for releases, but there's \nnot really any reason to do it if you're using the tag to just communicate \nwith other people (aka \"look, here is the thing I want you to merge\") \ninside a company or group.\n\nSo publishing lightweight tags makes perfect sense in that situation. I \nthink it's probably a nicer idea to have some way to specify \"don't \npublish\" either per-remote or just generally (ie have a rule something \nlike \"refs/tags/local/\" are not pushed or pulled unless explicitly asked \nfor).\n\n\t\tLinus\n"},{"id":"40518","messageId":"20070426170908.GS4489@pasky.or.cz","threadId":"7842","inReplyTo":"200704260933.38677.andyparkins@gmail.com","subject":"Re: [PATCH 0/2] bookmarks","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-04-26T17:09:08Z","receivedAt":"2007-04-26T17:09:08Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, Apr 26, 2007 at 10:33:36AM CEST, Andy Parkins wrote:\n> On Thursday 2007 April 26, Andy Parkins wrote:\n> \n> > Actually how about this: an option in the remote section to turn off\n> > auto-following and then add fetch and push lines for the tags too - that\n> > means very minimal changes and then everyone's happy (where everyone =\n> > me ;-)).\n> \n> Funny.  I went looking to add the above facility, and lo-and-behold, it's \n> already there in the form of the remote.$remote.tagopt parameter.\n> \n> [remote \"origin\"]\n>    tagopt = --no-tags\n>    push = refs/tags/public:refs/tags/*\n>    fetch = refs/tags/*:refs/tags/public/*\n> \n> This does exactly what I want.  Once again, git is waaaay ahead of me :-)\n\nStill, I think it would be nice to have an \"out-of-the-box\" general\nsolution for this. And since as Junio said, it might be nice to have\nprivate heads as well, I might mention my ancient proposal to just keep\nrefs with filename starting with a dot (refs/tags/.foo, ...) private by\ndefault. I have discussed this with Junio and IIRC he wasn't very happy\nwith this proposal, but I can't remember his arguments now. :-(\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"40603","messageId":"f0t5s3$f1e$1@sea.gmane.org","threadId":"7842","inReplyTo":"4630C377.8000602@op5.se","subject":"Re: git-fetch and unannotated tags","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-04-27T15:50:22Z","receivedAt":"2007-04-27T15:50:22Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andreas Ericsson wrote:\n\n> Andy Parkins wrote:\n>> \n>> I'd be arguing for making not following unannotated tags the default, and then \n>> supply a switch to make them followed.  Is that too painful?  I think that's \n>> in keeping with the tradition that unannotated tags are, typically, not \n>> wanted in a central repository - the default update hook prevents it for \n>> example.\n> \n> Yup. I share your feelings about simple tags. However, unless the repo owner\n> has decided to explicitly push the simple tag to the repo, or fscked up by\n> doing \"git push --all\" when he had cruft in his own repo, those tags are\n> in fact part of the repo.\n> \n> In the \"oops\" case, I'd point this out to the owner so he/she can delete them\n> from the central repo (and enable the update-hook that barfs when simple tags\n> are pushed). If the owner actually wants the tags there, then they're\n> obviously important for some reason, so keeping them might make sense.\n\nYou can delete branch (ref?) using \"<branch>:\" refspec, if server you push to\nhas git new enough. HTH.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"40694","messageId":"7v7irvfzmn.fsf@assigned-by-dhcp.cox.net","threadId":"7842","inReplyTo":"f0t5s3$f1e$1@sea.gmane.org","subject":"Re: git-fetch and unannotated tags","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-29T06:44:48Z","receivedAt":"2007-04-29T06:44:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> writes:\n\n> You can delete branch (ref?) using \"<branch>:\" refspec, if server you push to\n> has git new enough. HTH.\n\nI think you mean\n\n\t$ git push $URL :refs/heads/i-do-not-want-this-branch-anymore\n\nthat is, colon before existing ref, not after.\n"}]}