{"thread":{"id":"28288","subject":"[PATCH] Clarify that '--tags' fetches tags only","startedAt":"2011-09-02T21:04:46Z","lastAt":"2011-10-01T22:06:53Z","messageCount":32,"participants":["Anatol Pomozov","Drew Northup","Michael Witten","Junio C Hamano","Daniel Johnson","Andrew Ardill","Peter Shenkin","Jakub Narebski"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"174771","messageId":"1314997486-29996-1-git-send-email-anatol.pomozov@gmail.com","threadId":"28288","inReplyTo":null,"subject":"[PATCH] Clarify that '--tags' fetches tags only","fromName":"Anatol Pomozov","fromEmail":"anatol.pomozov@gmail.com","sentAt":"2011-09-02T21:04:46Z","receivedAt":"2011-09-02T21:04:46Z","isPatch":true,"sender":{"key":"anatol.pomozov@gmail.com","avatar":"https://gravatar.com/avatar/71fc20093402ce987148294ec0999d025209e52da6762789ff248cf5c317645f?d=mp&s=160"},"body":"---\n Documentation/fetch-options.txt | 3 ++-\n 1 files changed, 2 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt\nindex 39d326a..37d2316 100644\n--- a/Documentation/fetch-options.txt\n+++ b/Documentation/fetch-options.txt\n@@ -63,7 +63,8 @@ ifndef::git-pull[]\n \tflag lets all tags and their associated objects be\n \tdownloaded. The default behavior for a remote may be\n \tspecified with the remote..tagopt setting. See\n-\tlinkgit:git-config[1].\n+\tlinkgit:git-config[1]. Note that if this option is specified\n+\tthen only tags are fetched, refs under refs/heads/* stay unchanged.\n \n --recurse-submodules[=yes|on-demand|no]::\n \tThis option controls if and under what conditions new commits of\n-- \n1.7.7.rc0.72.g4b5ea.dirty\n"},{"id":"174772","messageId":"1314998301.19039.117.camel@ddn-tmpdesk.its.maine.edu","threadId":"28288","inReplyTo":"1314997486-29996-1-git-send-email-anatol.pomozov@gmail.com","subject":"Re: [PATCH] Clarify that '--tags' fetches tags only","fromName":"Drew Northup","fromEmail":"drew.northup@maine.edu","sentAt":"2011-09-02T21:18:21Z","receivedAt":"2011-09-02T21:18:21Z","isPatch":true,"sender":{"key":"drew.northup@maine.edu","avatar":"https://avatars.githubusercontent.com/u/18331571?v=4"},"body":"On Fri, 2011-09-02 at 14:04 -0700, Anatol Pomozov wrote:\n\n> -\tlinkgit:git-config[1].\n> +\tlinkgit:git-config[1]. Note that if this option is specified\n> +\tthen only tags are fetched, refs under refs/heads/* stay unchanged.\n\nAnatol,\nLooks like a sane change to me. You might want to check\nDocumentation/SubmittingPatches in the git repository if you want Junio\nto include your patch. It is probably also worth CC-ing those whom did\nthe previous work on that documentation and the tags code to make sure\nyour change is correct.\n\n-- \n-Drew Northup\n________________________________________________\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"175969","messageId":"1316649176-32352-1-git-send-email-anatol.pomozov@gmail.com","threadId":"28288","inReplyTo":"1314997486-29996-1-git-send-email-anatol.pomozov@gmail.com","subject":"[PATCH] Clarify that '--tags' fetches tags only","fromName":"Anatol Pomozov","fromEmail":"anatol.pomozov@gmail.com","sentAt":"2011-09-21T23:52:56Z","receivedAt":"2011-09-21T23:52:56Z","isPatch":true,"sender":{"key":"anatol.pomozov@gmail.com","avatar":"https://gravatar.com/avatar/71fc20093402ce987148294ec0999d025209e52da6762789ff248cf5c317645f?d=mp&s=160"},"body":"'git fetch --tags' fetches tags only and leaves heads untouched.\nMany people are confused by the fact that 'git fetch --tags'\ndoes not fetch heads.\n\nSigned-off-by: Anatol Pomozov \n---\n Documentation/fetch-options.txt | 3 ++-\n 1 files changed, 2 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt\nindex 39d326a..37d2316 100644\n--- a/Documentation/fetch-options.txt\n+++ b/Documentation/fetch-options.txt\n@@ -63,7 +63,8 @@ ifndef::git-pull[]\n \tflag lets all tags and their associated objects be\n \tdownloaded. The default behavior for a remote may be\n \tspecified with the remote..tagopt setting. See\n-\tlinkgit:git-config[1].\n+\tlinkgit:git-config[1]. Note that if this option is specified\n+\tthen only tags are fetched, refs under refs/heads/* stay unchanged.\n \n --recurse-submodules[=yes|on-demand|no]::\n \tThis option controls if and under what conditions new commits of\n-- \n1.7.7.rc0.72.g4b5ea.dirty\n"},{"id":"175970","messageId":"CAMOZ1BuSd52woX0utOQ84gbCzBkZg3ATKnE+7G_BrD5_hUQSiQ@mail.gmail.com","threadId":"28288","inReplyTo":"1316649176-32352-1-git-send-email-anatol.pomozov@gmail.com","subject":"Re: [PATCH] Clarify that '--tags' fetches tags only","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-09-22T00:13:21Z","receivedAt":"2011-09-22T00:13:21Z","isPatch":true,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Wed, Sep 21, 2011 at 23:52, Anatol Pomozov wrote:\n> + linkgit:git-config[1]. Note that if this option is specified\n> + then only tags are fetched, refs under refs/heads/* stay unchanged.\n\nNote that if this option is specified, then only tags\nare fetched; refs under refs/heads/* are not changed.\n"},{"id":"175971","messageId":"7vwrd1z9it.fsf@alter.siamese.dyndns.org","threadId":"28288","inReplyTo":"CAMOZ1BuSd52woX0utOQ84gbCzBkZg3ATKnE+7G_BrD5_hUQSiQ@mail.gmail.com","subject":"Re: [PATCH] Clarify that '--tags' fetches tags only","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-09-22T00:49:14Z","receivedAt":"2011-09-22T00:49:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Witten writes:\n\n> On Wed, Sep 21, 2011 at 23:52, Anatol Pomozov wrote:\n>> + linkgit:git-config[1]. Note that if this option is specified\n>> + then only tags are fetched, refs under refs/heads/* stay unchanged.\n>\n> Note that if this option is specified, then only tags\n> are fetched; refs under refs/heads/* are not changed.\n\nCan we improve the wording without singling out refs/heads/* specifically?\n\nI think the updated wording is not desirable for two reasons.\n\nFor one thing, for the most newbies, I think refs/remotes/origin/* (not\nrefs/heads/*) would be the hierarchy that they may expect to get updated\nand surprised.\n\nWhen you give --tags (or any other refspec for that matter; --tags is\nmerely a short-hand for \"refs/tags/*:refs/tags/*\") explicitly from the\ncommand line, you are overriding the refspecs configured for the remote,\nand all the refs that are _not_ covered by the refspec you gave from the\ncommand line will stay unchanged, not just refs/heads/* but refs under\nother hierarchies (like refs/remotes/* and refs/notes/*). \n\nOnce the reader understands that the command line _overrides_ the\nconfigured fetch refspecs, everything else should fall naturally into\nplace without further explanation. For example,\n\n\t$ git pull origin frotz\n\nwould internally invoke \"git fetch origin another_branch\", and it would\nnot update any refs for the _same exact reason_ [*1*]. You are giving a\nrefspec from the command line (in this case, \"grab refs/heads/frotz, but\ndo not store it anywhere\"), and it overrides the usual fetch refspec that\nmay update \"+refs/heads/*:refs/remotes/origin/*\" (grab all refs at the\norigin under refs/heads/ hierarchy, and store in refs/remotes/origin).\n\n\n[Footnote]\n\n*1* The merging of the result would update the current branch but that is\na natural consequence of \"a pull integrates by running either a merge or a\nrebase after running a fetch\".\n"},{"id":"175972","messageId":"119711285.RuumktFLOq@hyperion","threadId":"28288","inReplyTo":"1316649176-32352-1-git-send-email-anatol.pomozov@gmail.com","subject":"Re: [PATCH] Clarify that '--tags' fetches tags only","fromName":"Daniel Johnson","fromEmail":"computerdruid@gmail.com","sentAt":"2011-09-22T01:14:16Z","receivedAt":"2011-09-22T01:14:16Z","isPatch":true,"sender":{"key":"computerdruid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/34696?v=4"},"body":"On Wednesday, September 21, 2011 04:52:56 PM Anatol Pomozov wrote:\n> @@ -63,7 +63,8 @@ ifndef::git-pull[]\n> \tflag lets all tags and their associated objects be\n> \tdownloaded. The default behavior for a remote may be\n> \tspecified with the remote..tagopt setting. See\n> -\tlinkgit:git-config[1].\n> +\tlinkgit:git-config[1]. Note that if this option is specified\n> +\tthen only tags are fetched, refs under refs/heads/* stay unchanged.\n\nI like this clarification. It would be better placed before the note about the \ntagopt setting, as it clarifies the statement before that (\"This flag lets all \ntags and their associated objects be downloaded.\")\n\nIn fact, the optimal solution might be to rework that sentence with the \nclarification from yours, so something like \"This flag lets all tags and their \nassociated objects be downloaded instead of\"...\n"},{"id":"175974","messageId":"CAMOZ1Bvxc+vcofb_KyeLS7Gy=KOtX1SKv72cXA2NtwgYCWA31A@mail.gmail.com","threadId":"28288","inReplyTo":"7vwrd1z9it.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Clarify that '--tags' fetches tags only","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-09-22T02:01:30Z","receivedAt":"2011-09-22T02:01:30Z","isPatch":true,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Thu, Sep 22, 2011 at 00:49, Junio C Hamano wrote:\n> --tags is merely a short-hand for \"refs/tags/*:refs/tags/*\")\n> explicitly from the command line\n\n[Disclaimer: I don't know the code or the semantics]\n\nWhy not just use that explanation?\n\n This option is merely a short-hand for writing\n the refspec `refs/tags/*:refs/tags/*'; consequently,\n using this option overrides any default refspec that\n would be used if no refspec were provided on the\n command line. That is,\n\n git fetch --tags origin frotz\n\n is equivalent to:\n\n git fetch origin frotz 'refs/tags/*:refs/tags/*'\n\nIn fact, if the command line parsing performed by `git fetch'\nis reasonably intelligent, then it might be worthwhile\nto relocate `--tags' in the example:\n\n That is,\n\n git fetch origin frotz --tags\n\n is equivalent to:\n\n git fetch origin frotz 'refs/tags/*:refs/tags/*'\n"},{"id":"175975","messageId":"CAMOZ1Bt6gGVd6QuRZduZ4mJ=eoZ9d7xK-WfwZ3G-+oswT0RN_Q@mail.gmail.com","threadId":"28288","inReplyTo":"CAMOZ1Bvxc+vcofb_KyeLS7Gy=KOtX1SKv72cXA2NtwgYCWA31A@mail.gmail.com","subject":"Re: [PATCH] Clarify that '--tags' fetches tags only","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-09-22T02:07:59Z","receivedAt":"2011-09-22T02:07:59Z","isPatch":true,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Thu, Sep 22, 2011 at 02:01, Michael Witten wrote:\n> On Thu, Sep 22, 2011 at 00:49, Junio C Hamano wrote:\n>> --tags is merely a short-hand for \"refs/tags/*:refs/tags/*\")\n>> explicitly from the command line\n>\n> [Disclaimer: I don't know the code or the semantics]\n>\n> Why not just use that explanation?\n>\n>  This option is merely a short-hand for writing\n>  the refspec `refs/tags/*:refs/tags/*'; consequently,\n>  using this option overrides any default refspec that\n>  would be used if no refspec were provided on the\n>  command line. That is,\n>\n>    git fetch --tags origin frotz\n>\n>  is equivalent to:\n>\n>    git fetch origin frotz 'refs/tags/*:refs/tags/*'\n>\n> In fact, if the command line parsing performed by `git fetch'\n> is reasonably intelligent, then it might be worthwhile\n> to relocate `--tags' in the example:\n>\n>  That is,\n>\n>    git fetch origin frotz --tags\n>\n>  is equivalent to:\n>\n>    git fetch origin frotz 'refs/tags/*:refs/tags/*'\n>\n\nMaybe this is less confusing for the example:\n\n That is,\n\n git fetch origin --tags\n git fetch origin frotz --tags bar\n\n are equivalent to:\n\n git fetch origin 'refs/tags/*:refs/tags/*'\n git fetch origin frotz 'refs/tags/*:refs/tags/*' bar\n"},{"id":"175978","messageId":"CAH5451nb=DTed2kAVNQmFBbGFJ9zvQAtBE+VCzKqZfGMgYpx5w@mail.gmail.com","threadId":"28288","inReplyTo":"CAMOZ1Bt6gGVd6QuRZduZ4mJ=eoZ9d7xK-WfwZ3G-+oswT0RN_Q@mail.gmail.com","subject":"Re: [PATCH] Clarify that '--tags' fetches tags only","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2011-09-22T03:13:03Z","receivedAt":"2011-09-22T03:13:03Z","isPatch":true,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 22 September 2011 12:07, Michael Witten wrote:\n> On Thu, Sep 22, 2011 at 02:01, Michael Witten wrote:\n>> On Thu, Sep 22, 2011 at 00:49, Junio C Hamano wrote:\n>>> --tags is merely a short-hand for \"refs/tags/*:refs/tags/*\")\n>>> explicitly from the command line\n>>\n>> [Disclaimer: I don't know the code or the semantics]\n>>\n>> Why not just use that explanation?\n>>\n>>  This option is merely a short-hand for writing\n>>  the refspec `refs/tags/*:refs/tags/*'; consequently,\n>>  using this option overrides any default refspec that\n>>  would be used if no refspec were provided on the\n>>  command line. That is,\n>>\n>>    git fetch --tags origin frotz\n>>\n>>  is equivalent to:\n>>\n>>    git fetch origin frotz 'refs/tags/*:refs/tags/*'\n>>\n>> In fact, if the command line parsing performed by `git fetch'\n>> is reasonably intelligent, then it might be worthwhile\n>> to relocate `--tags' in the example:\n>>\n>>  That is,\n>>\n>>    git fetch origin frotz --tags\n>>\n>>  is equivalent to:\n>>\n>>    git fetch origin frotz 'refs/tags/*:refs/tags/*'\n>>\n>\n> Maybe this is less confusing for the example:\n>\n>  That is,\n>\n>    git fetch origin --tags\n>    git fetch origin frotz --tags bar\n>\n>  are equivalent to:\n>\n>    git fetch origin 'refs/tags/*:refs/tags/*'\n>    git fetch origin frotz 'refs/tags/*:refs/tags/*' bar\n\nThis will only help people who understand that tags are just refs\nstored in refs/tags, and who understand the 'ref:ref' syntax. I think\nit is a good example to have, but people can understand the process\nand results of 'pulling/fetching a tag' without necessarily needing to\nknow that tags are stored somewhere, or knowing the exact fetch\nmechanism. If these need to be documented, it should be in the\nappropriate place (which I don't think is here).\n\nI think we are skirting around the real issue, and that is that\npulling tags will often grab objects that are *meant* to be on a\nremote branch (from the user's perspective) but that appear to be\nhanging because the remote branch ref was not updated at the same\ntime. Perhaps an example or explanation of why this is the case would\nbe more useful?\n\nMaybe:\n\nNote that if this option is specified, then only tags\nare fetched. No other refs, such as a remote tracking\nbranch, will be updated, even if it has been updated\non the remote end.\n\nextra info on how this option is merely a short-hand for writing the\nrefspec `refs/tags/*:refs/tags/* could go here\n\n\nRegards,\nAndrew\n"},{"id":"175979","messageId":"CAMOZ1BtPJ_Ddxo1UG2cxJMnGv9y8sR0rAyk3d_5JEz4kLsUQJQ@mail.gmail.com","threadId":"28288","inReplyTo":"CAH5451nb=DTed2kAVNQmFBbGFJ9zvQAtBE+VCzKqZfGMgYpx5w@mail.gmail.com","subject":"Re: [PATCH] Clarify that '--tags' fetches tags only","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-09-22T03:24:42Z","receivedAt":"2011-09-22T03:24:42Z","isPatch":true,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Thu, Sep 22, 2011 at 03:13, Andrew Ardill wrote:\n> On 22 September 2011 12:07, Michael Witten wrote:\n>> On Thu, Sep 22, 2011 at 02:01, Michael Witten wrote:\n>>> On Thu, Sep 22, 2011 at 00:49, Junio C Hamano wrote:\n>>>> --tags is merely a short-hand for \"refs/tags/*:refs/tags/*\")\n>>>> explicitly from the command line\n>>>\n>>> [Disclaimer: I don't know the code or the semantics]\n>>>\n>>> Why not just use that explanation?\n>>>\n>>>  This option is merely a short-hand for writing\n>>>  the refspec `refs/tags/*:refs/tags/*'; consequently,\n>>>  using this option overrides any default refspec that\n>>>  would be used if no refspec were provided on the\n>>>  command line. That is,\n>>>\n>>>    git fetch --tags origin frotz\n>>>\n>>>  is equivalent to:\n>>>\n>>>    git fetch origin frotz 'refs/tags/*:refs/tags/*'\n>>>\n>>> In fact, if the command line parsing performed by `git fetch'\n>>> is reasonably intelligent, then it might be worthwhile\n>>> to relocate `--tags' in the example:\n>>>\n>>>  That is,\n>>>\n>>>    git fetch origin frotz --tags\n>>>\n>>>  is equivalent to:\n>>>\n>>>    git fetch origin frotz 'refs/tags/*:refs/tags/*'\n>>>\n>>\n>> Maybe this is less confusing for the example:\n>>\n>>  That is,\n>>\n>>    git fetch origin --tags\n>>    git fetch origin frotz --tags bar\n>>\n>>  are equivalent to:\n>>\n>>    git fetch origin 'refs/tags/*:refs/tags/*'\n>>    git fetch origin frotz 'refs/tags/*:refs/tags/*' bar\n>\n> This will only help people who understand that tags are just refs\n> stored in refs/tags, and who understand the 'ref:ref' syntax. I think\n> it is a good example to have, but people can understand the process\n> and results of 'pulling/fetching a tag' without necessarily needing to\n> know that tags are stored somewhere, or knowing the exact fetch\n> mechanism. If these need to be documented, it should be in the\n> appropriate place (which I don't think is here).\n>\n> I think we are skirting around the real issue, and that is that\n> pulling tags will often grab objects that are *meant* to be on a\n> remote branch (from the user's perspective) but that appear to be\n> hanging because the remote branch ref was not updated at the same\n> time. Perhaps an example or explanation of why this is the case would\n> be more useful?\n>\n> Maybe:\n>\n> Note that if this option is specified, then only tags\n> are fetched. No other refs, such as a remote tracking\n> branch, will be updated, even if it has been updated\n> on the remote end.\n>\n> extra info on how this option is merely a short-hand for writing the\n> refspec `refs/tags/*:refs/tags/* could go here\n\nJunio just explained why your description is inadequate and confusing.\n\nThere's so much confusion around git exactly because people are always\ntrying to hide just WTF is going on (especially by using TERRIBLE\nterms like `branch'; see my numerous discussions).\n\nIf I were a newbie and were to read the text that I just proferred as\na clarification of --tags, then I would next look up just WTF a\nrefspec is, and then a branch, and then...\n\nYou see? That's exactly how it should work. People should be given\ndescriptions that arm them with the terms necessary to look up more\ninformation. We need to stop writing documentation for that\nhypothetical idiot who doesn't know his ass from his own face. We need\nto cater to those people who intend to read documentation for the\npurpose of understanding the system---not for the purpose of gettin'\nshit dun with any half-baked notion that is good enough for the most\nsimplistic situation.\n\nI'm sending in a patch presently.\n"},{"id":"175980","messageId":"58d5d7abced4468ea7587a8aeddfb5ed-mfwitten@gmail.com","threadId":"28288","inReplyTo":"CAMOZ1BtPJ_Ddxo1UG2cxJMnGv9y8sR0rAyk3d_5JEz4kLsUQJQ@mail.gmail.com","subject":"[PATCH] Docs: Clarify the --tags option of `git fetch'","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":null,"receivedAt":"2011-09-22T03:24:42Z","isPatch":true,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"See the discussion starting here:\n\n [PATCH] Clarify that '--tags' fetches tags only\n Message-ID: <1314997486-29996-1-git-send-email-anatol.pomozov@gmail.com>\n http://thread.gmane.org/gmane.comp.version-control.git/180636\n\nSuggested-by: Anatol Pomozov \nSigned-off-by: Michael Witten \n---\n Documentation/fetch-options.txt | 21 ++++++++++++++++++---\n 1 files changed, 18 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt\nindex 39d326a..fb743fa 100644\n--- a/Documentation/fetch-options.txt\n+++ b/Documentation/fetch-options.txt\n@@ -61,9 +61,24 @@ ifndef::git-pull[]\n \tobjects reachable from the branch heads that are being\n \ttracked will not be fetched by this mechanism. This\n \tflag lets all tags and their associated objects be\n-\tdownloaded. The default behavior for a remote may be\n-\tspecified with the remote..tagopt setting. See\n-\tlinkgit:git-config[1].\n+\tdownloaded.\n++\n+This option is merely a short-hand for writing the\n+refspec `refs/tags/\\*:refs/tags/\\*'; consequently,\n+using this option overrides any default refspec that\n+would be used if no refspec were provided on the\n+command line. That is,\n++\n+\tgit fetch origin --tags\n+\tgit fetch origin frotz --tags bar\n++\n+are equivalent to:\n++\t\n+\tgit fetch origin 'refs/tags/*:refs/tags/*'\n+\tgit fetch origin frotz 'refs/tags/*:refs/tags/*' bar\n++\n+The default behavior for a remote may be specified with\n+the remote..tagopt setting. See linkgit:git-config[1].\n \n --recurse-submodules[=yes|on-demand|no]::\n \tThis option controls if and under what conditions new commits of\n-- \n1.7.6.409.ge7a85\n"},{"id":"175981","messageId":"CAMOZ1BuunD4x9eWMseJcJ1nWszmo8eR56uZQ2AVO+4PLmhq0PA@mail.gmail.com","threadId":"28288","inReplyTo":"58d5d7abced4468ea7587a8aeddfb5ed-mfwitten@gmail.com","subject":"Re: [PATCH] Docs: Clarify the --tags option of `git fetch'","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-09-22T03:48:57Z","receivedAt":"2011-09-22T03:48:57Z","isPatch":true,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Thu, Sep 22, 2011 at 03:39, Michael Witten wrote:\n> ...\n> +This option is merely a short-hand for writing the\n> ...\n\nJunio, make that `shorthand', if you please.\n"},{"id":"175982","messageId":"7vsjnpz0ng.fsf@alter.siamese.dyndns.org","threadId":"28288","inReplyTo":"CAMOZ1Bvxc+vcofb_KyeLS7Gy=KOtX1SKv72cXA2NtwgYCWA31A@mail.gmail.com","subject":"Re: [PATCH] Clarify that '--tags' fetches tags only","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-09-22T04:00:51Z","receivedAt":"2011-09-22T04:00:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Witten writes:\n\n> That is,\n>\n> git fetch origin frotz --tags\n>\n> is equivalent to:\n>\n> git fetch origin frotz 'refs/tags/*:refs/tags/*'\n\nNo matter what you do, please do not introduce a bad example that violates\nthe usual command line syntax convention to have subcommand (e.g. fetch),\noptions meant for the subcommand (e.g. --tags) and then other arguments.\n"},{"id":"175983","messageId":"872e5c09ebf24edc8ebd4351e99864c2-mfwitten@gmail.com","threadId":"28288","inReplyTo":"7vsjnpz0ng.fsf@alter.siamese.dyndns.org","subject":"[PATCH v2] Docs: Clarify the --tags option of `git fetch'","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":null,"receivedAt":"2011-09-22T04:00:51Z","isPatch":true,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Wed, 21 Sep 2011 21:00:51 -0700, Junio C Hamano wrote:\n\n> Michael Witten writes:\n>\n>> That is,\n>>\n>> git fetch origin frotz --tags\n>>\n>> is equivalent to:\n>>\n>> git fetch origin frotz 'refs/tags/*:refs/tags/*'\n>\n> No matter what you do, please do not introduce a bad example that violates\n> the usual command line syntax convention to have subcommand (e.g. fetch),\n> options meant for the subcommand (e.g. --tags) and then other arguments.\n\nToo bad; I think it really supplements the description well.\n\nIn any case:\n\n * The example has been changed as per your wish.\n * `short-hand' has been changed to `shorthand'.\n * Trailing whitespace has been removed from a line.\n\n8<-----------8<-----------8<-----------8<-----------8<-----------8<-----------\n\nSee the discussion starting here:\n\n [PATCH] Clarify that '--tags' fetches tags only\n Message-ID: <1314997486-29996-1-git-send-email-anatol.pomozov@gmail.com>\n http://thread.gmane.org/gmane.comp.version-control.git/180636\n\nSuggested-by: Anatol Pomozov \nSigned-off-by: Michael Witten \n---\n Documentation/fetch-options.txt | 21 ++++++++++++++++++---\n 1 files changed, 18 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt\nindex 39d326a..da594bd 100644\n--- a/Documentation/fetch-options.txt\n+++ b/Documentation/fetch-options.txt\n@@ -61,9 +61,24 @@ ifndef::git-pull[]\n \tobjects reachable from the branch heads that are being\n \ttracked will not be fetched by this mechanism. This\n \tflag lets all tags and their associated objects be\n-\tdownloaded. The default behavior for a remote may be\n-\tspecified with the remote..tagopt setting. See\n-\tlinkgit:git-config[1].\n+\tdownloaded.\n++\n+This option is merely a shorthand for writing the\n+refspec `refs/tags/\\*:refs/tags/\\*'; consequently,\n+using this option overrides any default refspec that\n+would be used if no refspec were provided on the\n+command line. That is,\n++\n+\tgit fetch origin --tags\n+\tgit fetch origin --tags frotz\n++\n+are equivalent to:\n++\n+\tgit fetch origin 'refs/tags/*:refs/tags/*'\n+\tgit fetch origin 'refs/tags/*:refs/tags/*' frotz\n++\n+The default behavior for a remote may be specified with\n+the remote..tagopt setting. See linkgit:git-config[1].\n \n --recurse-submodules[=yes|on-demand|no]::\n \tThis option controls if and under what conditions new commits of\n-- \n1.7.6.409.ge7a85\n"},{"id":"175984","messageId":"7vfwjpyzds.fsf@alter.siamese.dyndns.org","threadId":"28288","inReplyTo":"CAMOZ1BtPJ_Ddxo1UG2cxJMnGv9y8sR0rAyk3d_5JEz4kLsUQJQ@mail.gmail.com","subject":"Re: [PATCH] Clarify that '--tags' fetches tags only","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-09-22T04:28:15Z","receivedAt":"2011-09-22T04:28:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Witten writes:\n\n> On Thu, Sep 22, 2011 at 03:13, Andrew Ardill wrote:\n>>\n>> Maybe:\n>>\n>> Note that if this option is specified, then only tags\n>> are fetched. No other refs, such as a remote tracking\n>> branch, will be updated, even if it has been updated\n>> on the remote end.\n>>\n>> extra info on how this option is merely a short-hand for writing the\n>> refspec `refs/tags/*:refs/tags/* could go here\n>\n> Junio just explained why your description is inadequate and confusing.\n> ...\n> If I were a newbie and were to read the text that I just proferred as\n> a clarification of --tags, then I would next look up just WTF a\n> refspec is, and then a branch, and then...\n\nI do agree with you that it is a futile exercise to sweep fundamental\nconcepts under the rug, fearing that they are too detailed and too hard\nfor the casual readers. By understanding how simple the fundamental\nconcepts and rules are, readers can have a coherent and clear mental model\nof the world and synthesize these fundamental rules to understand more\ncomplex operations the Porcelain commands offer to help every day tasks.\n\nI however do not think, and I certainly did not mean, that the description\nof \"--tags\" option is necessarily the place we should bombard a new user\nwith the term refspec and \"refs/tags/*:refs/tags/*\" syntax.\n\nI expect the readers to, and I hope the documentation to help them to,\nunderstand the following three basic facts and rules before diving into\ndescriptions of individual options, such as the paragraph we are\ndiscussing:\n\n * \"git fetch\" command serves two purposes:\n\n (1) It transfers objects the repository the command is invoked in does\n not have from the remote repository. The objects transferred are the\n commits that are necessary to complete the ancestry chain of _some_\n history, and data (i.e. trees and blobs) associated to use these\n commits.\n\n (2) It optionally can update the local refs (e.g. branches and tags)\n with copies of the refs taken from the remote repository.\n\n * In the above, the user needs to tell the command two things. One is\n \"where the remote repository is\". The other is \"what refs to fetch and\n (optionally) how to store them\". The latter \"what to fetch\" also\n determines what that \"_some_ history\" above is (i.e. everything\n reachable from the refs that are fetched).\n\n * \"What to fetch and how to store\" have a default, recorded in the\n repository configuration file, that is used when the user does not give\n that information to the command from the command line. If the user does\n give that information from the command line, that default is not used\n at all. IOW, the command line overrides the default.\n\nWith that understanding, the _only_ thing that \"--tags\" description needs\nto talk about is that it is an explicit way to give that \"what to fetch\nand how to store\" information from the command line. It instructs the\ncommand to fetch all the tags from the remote repository and store them\nlocally.\n\nIf the logic flow of the document presents the list of options before\nhelping the readers understand the above basic facts and rules, then I\nthink _that_ is the problem with the document we need to be addressing,\nnot the description of an individual option such as \"--tags\".\n"},{"id":"175987","messageId":"686c38876d5a4ad6bfac67ca77fe9bb3-mfwitten@gmail.com","threadId":"28288","inReplyTo":"7vfwjpyzds.fsf@alter.siamese.dyndns.org","subject":"[PATCH v3] Docs: Clarify the --tags option of `git fetch'","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":null,"receivedAt":"2011-09-22T05:58:37Z","isPatch":true,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Wed, 21 Sep 2011 21:28:15 -0700, Junio C Hamano wrote:\n\n> I expect the readers to, and I hope the documentation to help them to,\n> understand the following three basic facts and rules before diving into\n> descriptions of individual options, such as the paragraph we are\n> discussing:\n>\n> * \"git fetch\" command serves two purposes:\n>\n> (1) It transfers objects the repository the command is invoked in does\n> not have from the remote repository. The objects transferred are the\n> commits that are necessary to complete the ancestry chain of _some_\n> history, and data (i.e. trees and blobs) associated to use these\n> commits.\n>\n> (2) It optionally can update the local refs (e.g. branches and tags)\n> with copies of the refs taken from the remote repository.\n>\n> * In the above, the user needs to tell the command two things. One is\n> \"where the remote repository is\". The other is \"what refs to fetch and\n> (optionally) how to store them\". The latter \"what to fetch\" also\n> determines what that \"_some_ history\" above is (i.e. everything\n> reachable from the refs that are fetched).\n>\n> * \"What to fetch and how to store\" have a default, recorded in the\n> repository configuration file, that is used when the user does not give\n> that information to the command from the command line. If the user does\n> give that information from the command line, that default is not used\n> at all. IOW, the command line overrides the default.\n>\n> With that understanding, the _only_ thing that \"--tags\" description needs\n> to talk about is that it is an explicit way to give that \"what to fetch\n> and how to store\" information from the command line. It instructs the\n> command to fetch all the tags from the remote repository and store them\n> locally.\n\nFor at least the near term, this patch may do a pretty good job of\nachieving those goals without having to change too much; I do some\ncareful maneuvering to avoid mentioning refspecs until quite late\nin the description.\n\n8<-----------8<-----------8<-----------8<-----------8<-----------8<-----------\n\nSee the discussion starting here:\n\n [PATCH] Clarify that '--tags' fetches tags only\n Message-ID: <1314997486-29996-1-git-send-email-anatol.pomozov@gmail.com>\n http://thread.gmane.org/gmane.comp.version-control.git/180636\n\nSuggested-by: Anatol Pomozov \nSigned-off-by: Michael Witten \n---\n Documentation/fetch-options.txt | 31 +++++++++++++++++++++++--------\n 1 files changed, 23 insertions(+), 8 deletions(-)\n\ndiff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt\nindex 39d326a..4cc5a80 100644\n--- a/Documentation/fetch-options.txt\n+++ b/Documentation/fetch-options.txt\n@@ -56,14 +56,29 @@ endif::git-pull[]\n ifndef::git-pull[]\n -t::\n --tags::\n-\tMost of the tags are fetched automatically as branch\n-\theads are downloaded, but tags that do not point at\n-\tobjects reachable from the branch heads that are being\n-\ttracked will not be fetched by this mechanism. This\n-\tflag lets all tags and their associated objects be\n-\tdownloaded. The default behavior for a remote may be\n-\tspecified with the remote..tagopt setting. See\n-\tlinkgit:git-config[1].\n+\tMost of a remote's tags are fetched automatically as branches are\n+\tdownloaded. However, git does not automatically fetch any tag that,\n+\twhen 'git fetch' completes, would not be reachable from any local\n+\tbranch head. This option tells git to fetch all tags (and their\n+\tassociated objects).\n++\n+The 'git fetch' command is often supplied with a default set of branch\n+heads to fetch, but using this option tells 'git fetch' to ignore those\n+defaults.\n++\n+This option is merely a shorthand for writing the refspec\n+`refs/tags/\\*:refs/tags/\\*'; that is,\n++\n+\tgit fetch origin --tags\n+\tgit fetch origin --tags frotz\n++\n+are equivalent to:\n++\n+\tgit fetch origin 'refs/tags/*:refs/tags/*'\n+\tgit fetch origin frotz 'refs/tags/*:refs/tags/*'\n++\n+The default behavior for a remote may be specified with\n+the remote..tagopt setting. See linkgit:git-config[1].\n \n --recurse-submodules[=yes|on-demand|no]::\n \tThis option controls if and under what conditions new commits of\n-- \n1.7.6.409.ge7a85\n"},{"id":"175999","messageId":"7v1uv8zen5.fsf@alter.siamese.dyndns.org","threadId":"28288","inReplyTo":"686c38876d5a4ad6bfac67ca77fe9bb3-mfwitten@gmail.com","subject":"Re: [PATCH v3] Docs: Clarify the --tags option of `git fetch'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-09-22T17:10:54Z","receivedAt":"2011-09-22T17:10:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Witten writes:\n\n> 8<-----------8<-----------8<-----------8<-----------8<-----------8<-----------\n>\n> See the discussion starting here:\n>\n> [PATCH] Clarify that '--tags' fetches tags only\n> Message-ID: <1314997486-29996-1-git-send-email-anatol.pomozov@gmail.com>\n> http://thread.gmane.org/gmane.comp.version-control.git/180636\n\nIt is a good practice to point to earlier discussions while polishing\npatch, and it also is good to include pointers in the commit log message\nas a supporting material (additional reading), but that is _NOT_ a\nsubstitute for a properly written commit log message. You need to state\nwhat problem you are trying to fix and how the proposed patch fixes it.\n\n> Documentation/fetch-options.txt | 31 +++++++++++++++++++++++--------\n> 1 files changed, 23 insertions(+), 8 deletions(-)\n>\n> diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt\n> index 39d326a..4cc5a80 100644\n> --- a/Documentation/fetch-options.txt\n> +++ b/Documentation/fetch-options.txt\n> @@ -56,14 +56,29 @@ endif::git-pull[]\n> ifndef::git-pull[]\n> -t::\n> --tags::\n> -\tMost of the tags are fetched automatically as branch\n> -\theads are downloaded, but tags that do not point at\n> -\tobjects reachable from the branch heads that are being\n> -\ttracked will not be fetched by this mechanism. This\n> -\tflag lets all tags and their associated objects be\n> -\tdownloaded. The default behavior for a remote may be\n> -\tspecified with the remote..tagopt setting. See\n> -\tlinkgit:git-config[1].\n> +\tMost of a remote's tags are fetched automatically as branches are\n> +\tdownloaded. However, git does not automatically fetch any tag that,\n> +\twhen 'git fetch' completes, would not be reachable from any local\n> +\tbranch head. This option tells git to fetch all tags (and their\n> +\tassociated objects).\n\nI would suggest clarifying the beginning of \"git fetch --help\" like the\nattached patch. With that knowledge at hand, the readers do not need the\nfuzzy \"Most of ... are fetched\" (leaving them wondering \"what about the\nrest, and how that Most is determined?\"); we only need to say something\nlike \"fetch all the tags from the remote and store them locally\".\n\n Documentation/git-fetch.txt | 21 ++++++++++-----------\n 1 files changed, 10 insertions(+), 11 deletions(-)\n\ndiff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt\nindex 60ac8d2..c6c7236 100644\n--- a/Documentation/git-fetch.txt\n+++ b/Documentation/git-fetch.txt\n@@ -19,20 +19,19 @@ SYNOPSIS\n \n DESCRIPTION\n -----------\n-Fetches named heads or tags from one or more other repositories,\n-along with the objects necessary to complete them.\n+Fetches branches and tags (collectively known as 'refs') from one or more\n+other repositories, along with the objects necessary to complete them.\n+Which refs are fetched are determined by the arguments, if\n+given. Otherwise the default configured for the \n+are used (see \"REMOTES\" section below for how works).\n \n-The ref names and their object names of fetched refs are stored\n-in `.git/FETCH_HEAD`. This information is left for a later merge\n-operation done by 'git merge'.\n+The ref names and their object names are also stored in `.git/FETCH_HEAD`.\n+This information is used by 'git pull' that invokes this command.\n \n When stores the fetched result in remote-tracking branches,\n-the tags that point at these branches are automatically\n-followed. This is done by first fetching from the remote using\n-the given s, and if the repository has objects that are\n-pointed by remote tags that it does not yet have, then fetch\n-those missing tags. If the other end has tags that point at\n-branches you are not interested in, you will not get them.\n+the tags that point at commits on these branches are also fetched. Tags\n+at the remote that point at commits that are not on these remote-tracking \n+branches are not fetched by this mechanism (use `--tags` option to fetch them).\n \n 'git fetch' can fetch from either a single named repository,\n or from several repositories at once if is given and\n"},{"id":"176005","messageId":"CAMOZ1BtBEHae7x-cn=DtnzwoyC_sYedgFmyNwrDuju+kcJU4hg@mail.gmail.com","threadId":"28288","inReplyTo":"7v1uv8zen5.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v3] Docs: Clarify the --tags option of `git fetch'","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-09-22T17:35:02Z","receivedAt":"2011-09-22T17:35:02Z","isPatch":true,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Thu, Sep 22, 2011 at 17:10, Junio C Hamano wrote:\n> Michael Witten writes:\n>\n>> 8<-----------8<-----------8<-----------8<-----------8<-----------8<-----------\n>>\n>> See the discussion starting here:\n>>\n>>   [PATCH] Clarify that '--tags' fetches tags only\n>>   Message-ID: <1314997486-29996-1-git-send-email-anatol.pomozov@gmail.com>\n>>   http://thread.gmane.org/gmane.comp.version-control.git/180636\n>\n> It is a good practice to point to earlier discussions while polishing\n> patch, and it also is good to include pointers in the commit log message\n> as a supporting material (additional reading), but that is _NOT_ a\n> substitute for a properly written commit log message. You need to state\n> what problem you are trying to fix and how the proposed patch fixes it.\n>\n>>  Documentation/fetch-options.txt |   31 +++++++++++++++++++++++--------\n>>  1 files changed, 23 insertions(+), 8 deletions(-)\n>>\n>> diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt\n>> index 39d326a..4cc5a80 100644\n>> --- a/Documentation/fetch-options.txt\n>> +++ b/Documentation/fetch-options.txt\n>> @@ -56,14 +56,29 @@ endif::git-pull[]\n>>  ifndef::git-pull[]\n>>  -t::\n>>  --tags::\n>> -     Most of the tags are fetched automatically as branch\n>> -     heads are downloaded, but tags that do not point at\n>> -     objects reachable from the branch heads that are being\n>> -     tracked will not be fetched by this mechanism.  This\n>> -     flag lets all tags and their associated objects be\n>> -     downloaded. The default behavior for a remote may be\n>> -     specified with the remote..tagopt setting. See\n>> -     linkgit:git-config[1].\n>> +     Most of a remote's tags are fetched automatically as branches are\n>> +     downloaded. However, git does not automatically fetch any tag that,\n>> +     when 'git fetch' completes, would not be reachable from any local\n>> +     branch head.  This option tells git to fetch all tags (and their\n>> +     associated objects).\n>\n> I would suggest clarifying the beginning of \"git fetch --help\" like the\n> attached patch. With that knowledge at hand, the readers do not need the\n> fuzzy \"Most of ... are fetched\" (leaving them wondering \"what about the\n> rest, and how that Most is determined?\"); we only need to say something\n> like \"fetch all the tags from the remote and store them locally\".\n>\n>  Documentation/git-fetch.txt |   21 ++++++++++-----------\n>  1 files changed, 10 insertions(+), 11 deletions(-)\n>\n> diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt\n> index 60ac8d2..c6c7236 100644\n> --- a/Documentation/git-fetch.txt\n> +++ b/Documentation/git-fetch.txt\n> @@ -19,20 +19,19 @@ SYNOPSIS\n>\n>  DESCRIPTION\n>  -----------\n> -Fetches named heads or tags from one or more other repositories,\n> -along with the objects necessary to complete them.\n> +Fetches branches and tags (collectively known as 'refs') from one or more\n> +other repositories, along with the objects necessary to complete them.\n> +Which refs are fetched are determined by the arguments, if\n> +given. Otherwise the default configured for the \n> +are used (see \"REMOTES\" section below for how works).\n>\n> -The ref names and their object names of fetched refs are stored\n> -in `.git/FETCH_HEAD`.  This information is left for a later merge\n> -operation done by 'git merge'.\n> +The ref names and their object names are also stored in `.git/FETCH_HEAD`.\n> +This information is used by 'git pull' that invokes this command.\n>\n>  When stores the fetched result in remote-tracking branches,\n> -the tags that point at these branches are automatically\n> -followed.  This is done by first fetching from the remote using\n> -the given s, and if the repository has objects that are\n> -pointed by remote tags that it does not yet have, then fetch\n> -those missing tags.  If the other end has tags that point at\n> -branches you are not interested in, you will not get them.\n> +the tags that point at commits on these branches are also fetched. Tags\n> +at the remote that point at commits that are not on these remote-tracking\n> +branches are not fetched by this mechanism (use `--tags` option to fetch them).\n>\n>  'git fetch' can fetch from either a single named repository,\n>  or from several repositories at once if is given and\n>\n\nThe only problem is that none of what you say seems to be true.\n\n * The glossary very distinctly differentiates the\n term `branch' from `branch head'.\n\n * From skimming the code, it would seem that remote-tracking\n branch [*heads*] are not at all the determining factor for\n whether tags are automatically fetched. Rather, the\n determining factor is much more relaxed: Tags are fetched\n when a refspec's field is non-empty; it just so\n happens that a is usually non-empty because at least\n one remote-tracking branch [*head*] is being updated, but\n keep in mind that the branch being updated need not be\n considered a remote-tracking branch.\n"},{"id":"176006","messageId":"CAMOZ1BtHUtZvQJMM0yhOumb8aq7NnHv8udPOVdciQE3=jNGq4Q@mail.gmail.com","threadId":"28288","inReplyTo":"CAMOZ1BtBEHae7x-cn=DtnzwoyC_sYedgFmyNwrDuju+kcJU4hg@mail.gmail.com","subject":"Re: [PATCH v3] Docs: Clarify the --tags option of `git fetch'","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-09-22T17:38:00Z","receivedAt":"2011-09-22T17:38:00Z","isPatch":true,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Thu, Sep 22, 2011 at 17:35, Michael Witten wrote:\n> On Thu, Sep 22, 2011 at 17:10, Junio C Hamano wrote:\n>> Michael Witten writes:\n>>\n>>> 8<-----------8<-----------8<-----------8<-----------8<-----------8<-----------\n>>>\n>>> See the discussion starting here:\n>>>\n>>>   [PATCH] Clarify that '--tags' fetches tags only\n>>>   Message-ID: <1314997486-29996-1-git-send-email-anatol.pomozov@gmail.com>\n>>>   http://thread.gmane.org/gmane.comp.version-control.git/180636\n>>\n>> It is a good practice to point to earlier discussions while polishing\n>> patch, and it also is good to include pointers in the commit log message\n>> as a supporting material (additional reading), but that is _NOT_ a\n>> substitute for a properly written commit log message. You need to state\n>> what problem you are trying to fix and how the proposed patch fixes it.\n>>\n>>>  Documentation/fetch-options.txt |   31 +++++++++++++++++++++++--------\n>>>  1 files changed, 23 insertions(+), 8 deletions(-)\n>>>\n>>> diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt\n>>> index 39d326a..4cc5a80 100644\n>>> --- a/Documentation/fetch-options.txt\n>>> +++ b/Documentation/fetch-options.txt\n>>> @@ -56,14 +56,29 @@ endif::git-pull[]\n>>>  ifndef::git-pull[]\n>>>  -t::\n>>>  --tags::\n>>> -     Most of the tags are fetched automatically as branch\n>>> -     heads are downloaded, but tags that do not point at\n>>> -     objects reachable from the branch heads that are being\n>>> -     tracked will not be fetched by this mechanism.  This\n>>> -     flag lets all tags and their associated objects be\n>>> -     downloaded. The default behavior for a remote may be\n>>> -     specified with the remote..tagopt setting. See\n>>> -     linkgit:git-config[1].\n>>> +     Most of a remote's tags are fetched automatically as branches are\n>>> +     downloaded. However, git does not automatically fetch any tag that,\n>>> +     when 'git fetch' completes, would not be reachable from any local\n>>> +     branch head.  This option tells git to fetch all tags (and their\n>>> +     associated objects).\n>>\n>> I would suggest clarifying the beginning of \"git fetch --help\" like the\n>> attached patch. With that knowledge at hand, the readers do not need the\n>> fuzzy \"Most of ... are fetched\" (leaving them wondering \"what about the\n>> rest, and how that Most is determined?\"); we only need to say something\n>> like \"fetch all the tags from the remote and store them locally\".\n>>\n>>  Documentation/git-fetch.txt |   21 ++++++++++-----------\n>>  1 files changed, 10 insertions(+), 11 deletions(-)\n>>\n>> diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt\n>> index 60ac8d2..c6c7236 100644\n>> --- a/Documentation/git-fetch.txt\n>> +++ b/Documentation/git-fetch.txt\n>> @@ -19,20 +19,19 @@ SYNOPSIS\n>>\n>>  DESCRIPTION\n>>  -----------\n>> -Fetches named heads or tags from one or more other repositories,\n>> -along with the objects necessary to complete them.\n>> +Fetches branches and tags (collectively known as 'refs') from one or more\n>> +other repositories, along with the objects necessary to complete them.\n>> +Which refs are fetched are determined by the arguments, if\n>> +given. Otherwise the default configured for the \n>> +are used (see \"REMOTES\" section below for how works).\n>>\n>> -The ref names and their object names of fetched refs are stored\n>> -in `.git/FETCH_HEAD`.  This information is left for a later merge\n>> -operation done by 'git merge'.\n>> +The ref names and their object names are also stored in `.git/FETCH_HEAD`.\n>> +This information is used by 'git pull' that invokes this command.\n>>\n>>  When stores the fetched result in remote-tracking branches,\n>> -the tags that point at these branches are automatically\n>> -followed.  This is done by first fetching from the remote using\n>> -the given s, and if the repository has objects that are\n>> -pointed by remote tags that it does not yet have, then fetch\n>> -those missing tags.  If the other end has tags that point at\n>> -branches you are not interested in, you will not get them.\n>> +the tags that point at commits on these branches are also fetched. Tags\n>> +at the remote that point at commits that are not on these remote-tracking\n>> +branches are not fetched by this mechanism (use `--tags` option to fetch them).\n>>\n>>  'git fetch' can fetch from either a single named repository,\n>>  or from several repositories at once if is given and\n>>\n>\n> The only problem is that none of what you say seems to be true.\n>\n>  * The glossary very distinctly differentiates the\n>    term `branch' from `branch head'.\n>\n>  * From skimming the code, it would seem that remote-tracking\n>    branch [*heads*] are not at all the determining factor for\n>    whether tags are automatically fetched. Rather, the\n>    determining factor is much more relaxed: Tags are fetched\n>    when a refspec's field is non-empty; it just so\n>    happens that a is usually non-empty because at least\n>    one remote-tracking branch [*head*] is being updated, but\n>    keep in mind that the branch being updated need not be\n>    considered a remote-tracking branch.\n\nDAMNIT\n\nThat last bit should use the world `head':\n\n but keep in mind that the branch *head* being updated\n need not be considered a remote-tracking branch [*head*].\n"},{"id":"176550","messageId":"loom.20110930T041939-332@post.gmane.org","threadId":"28288","inReplyTo":"119711285.RuumktFLOq@hyperion","subject":"Re: [PATCH] Clarify that '--tags' fetches tags only","fromName":"Peter Shenkin","fromEmail":"shenkin@gmail.com","sentAt":"2011-09-30T02:51:21Z","receivedAt":"2011-09-30T02:51:21Z","isPatch":true,"sender":{"key":"shenkin@gmail.com","avatar":"https://gravatar.com/avatar/52c52505b22c13500ceea15fda29f915e9968be9f67a9e4ee2a1721fc18a56e6?d=mp&s=160"},"body":"Hi,\n\nI just searched the List to see if there were any postings on\n\"fetch --tags\", because I was recently thrown for a loop by\nthe fact the this command retrieves only tags (and commits\nneeded to fulfill them). So I was very happy to find this\ndiscussion. I was actually trying to figure out whether the\nobserved behavior is a bug, given that there is no mention of\nit in the documentation.\n\nPerhaps it will be useful to say what would have been most\nhelpful for me. In the current documentation for \"fetch\n--tags\", one sentence reads, \"This flag lets all tags and\ntheir associated objects be downloaded.\" The following small\nmodification would, IMO, be sufficient: \"This flag causes all\ntags and their associated objects (only) to be downloaded.\"\n\nNow I have a related question. I always want to retrieve all\ntags from tracking branches when I do a \"git pull\". Right now,\nif I want to do this, it seem (unless I am missing something)\nthat I have to do \"git fetch --tags; git fetch; git merge\". Is\nthere a way I can put something into my .git/config file so\nthat I get this effect simply by doing a \"git pull\"? That's\nwhat I was trying to do when I added \"tagopt = --tags\".\n\nThanks,\n-P.\n"},{"id":"176559","messageId":"m3pqiio1xc.fsf@localhost.localdomain","threadId":"28288","inReplyTo":"loom.20110930T041939-332@post.gmane.org","subject":"Re: [PATCH] Clarify that '--tags' fetches tags only","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-09-30T08:44:13Z","receivedAt":"2011-09-30T08:44:13Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Peter Shenkin writes:\n\n[...]\n> Now I have a related question. I always want to retrieve all\n> tags from tracking branches when I do a \"git pull\". Right now,\n> if I want to do this, it seem (unless I am missing something)\n> that I have to do \"git fetch --tags; git fetch; git merge\". Is\n> there a way I can put something into my .git/config file so\n> that I get this effect simply by doing a \"git pull\"? That's\n> what I was trying to do when I added \"tagopt = --tags\".\n\nActually fetching of branches on remote into remote-tracking branches\nwould also fetch all tags that point to commits on fetched branches\n(so called \"autofollow\" feature).\n\nIf you want to fetch _all_ tags, you need to configure fetched\nbranches (e.g. via glob refspec). I think that then \"tagopt = --tags\"\nworks as expected then, as it is in addition to refspec not as the\nonly refspec; \"fetch = +refs/tags/*:refs/tags/*\" should work as well.\n\nHTH\n-- \nJakub Narębski\n"},{"id":"176569","messageId":"CAMOZ1BsTKBPArRF-LxoNOJcQarMWx-2a2UBoVjWN-96xJ3Ad8A@mail.gmail.com","threadId":"28288","inReplyTo":"loom.20110930T041939-332@post.gmane.org","subject":"Re: [PATCH] Clarify that '--tags' fetches tags only","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-09-30T13:23:48Z","receivedAt":"2011-09-30T13:23:48Z","isPatch":true,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Fri, Sep 30, 2011 at 02:51, Peter Shenkin wrote:\n> Perhaps it will be useful to say what would have been most\n> helpful for me. In the current documentation for \"fetch\n> --tags\", one sentence reads, \"This flag lets all tags and\n> their associated  objects be downloaded.\" The following small\n> modification would, IMO, be sufficient: \"This flag causes all\n> tags and their associated objects (only) to be downloaded.\"\n\nWell, you're missing the fact that it not only causes those to\nbe downloaded, but it also causes the defaults to be ignored,\nwhich is why you don't get the other stuff. You can still tell\ngit to fetch anything else you want in addition.\n\nSee here:\n\n [PATCH v3] Docs: Clarify the --tags option of `git fetch'\n Message-ID: <686c38876d5a4ad6bfac67ca77fe9bb3-mfwitten@gmail.com>\n http://article.gmane.org/gmane.comp.version-control.git/181887\n"},{"id":"176586","messageId":"7vwrcpoozk.fsf@alter.siamese.dyndns.org","threadId":"28288","inReplyTo":"loom.20110930T041939-332@post.gmane.org","subject":"Re: [PATCH] Clarify that '--tags' fetches tags only","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-09-30T18:37:51Z","receivedAt":"2011-09-30T18:37:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Peter Shenkin writes:\n\n> Perhaps it will be useful to say what would have been most\n> helpful for me. In the current documentation for \"fetch\n> --tags\", one sentence reads, \"This flag lets all tags and\n> their associated objects be downloaded.\" The following small\n> modification would, IMO, be sufficient: \"This flag causes all\n> tags and their associated objects (only) to be downloaded.\"\n\nHmm, from time to time we seem to see this kind of documentation\nsuggestion where:\n\n - We (try to) describe what xyzzy does by saying \"This is what xyzzy\n does\". We specifically do not say \"In addition to what normally\n happens, xyzzy causes these additional things to happen.\"\n\n - The reader (somehow) assumes xyzzy does more than what we described in\n the documentation, even we did not say \"In addition to...\"; and then\n\n - A patch is proposed to add \"these other things are _not_ done\", after\n existing \"This is what xyzzy does\".\n\nAnd it is not limited to the description of this particular option.\n\nI think in general our documentation aims to spell out _all_ that happens,\nand explicitly say \"In addition to what normally happens\", \"This page\nlists only the most common ways\", etc., when such a clatification is\nneeded.\n\nI am wondering if there is a systemic failure that gives an impression\nthat by default the documentation is incomplete and all other unspecified\nthing also happens to the readers? If so are there things that we could\ndo better without going through individual description?\n"},{"id":"176623","messageId":"loom.20111001T073652-884@post.gmane.org","threadId":"28288","inReplyTo":"CAMOZ1BsTKBPArRF-LxoNOJcQarMWx-2a2UBoVjWN-96xJ3Ad8A@mail.gmail.com","subject":"Re: [PATCH] Clarify that '--tags' fetches tags only","fromName":"Peter Shenkin","fromEmail":"shenkin@gmail.com","sentAt":"2011-10-01T05:40:02Z","receivedAt":"2011-10-01T05:40:02Z","isPatch":true,"sender":{"key":"shenkin@gmail.com","avatar":"https://gravatar.com/avatar/52c52505b22c13500ceea15fda29f915e9968be9f67a9e4ee2a1721fc18a56e6?d=mp&s=160"},"body":"Michael Witten gmail.com> writes:\n> Well, you're missing the fact that it not only causes those to\n> be downloaded, but it also causes the defaults to be ignored,\n> which is why you don't get the other stuff. You can still tell\n> git to fetch anything else you want in addition.\n\nI was no longer missing it at the time I posted. \n\nBut that is indeed what I was missing when I first encountered \nthe behavior. The purpose of posting was to point out that \nwith a very small change in the documentation, I would not\nhave missed it. \n\n-P.\n"},{"id":"176624","messageId":"loom.20111001T074143-595@post.gmane.org","threadId":"28288","inReplyTo":"7vwrcpoozk.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Clarify that '--tags' fetches tags only","fromName":"Peter Shenkin","fromEmail":"shenkin@gmail.com","sentAt":"2011-10-01T05:51:12Z","receivedAt":"2011-10-01T05:51:12Z","isPatch":true,"sender":{"key":"shenkin@gmail.com","avatar":"https://gravatar.com/avatar/52c52505b22c13500ceea15fda29f915e9968be9f67a9e4ee2a1721fc18a56e6?d=mp&s=160"},"body":"Junio C Hamano pobox.com> writes:\n> I think in general our documentation aims to spell out _all_ that happens,\n...\n \n> I am wondering if there is a systemic failure...\n> ,,,If so are there things that we could\n> do better without going through individual description?\n\n\nYes, I would say that there is one obvious \nsystemic failure. \n\nNowhere is it documented (as far as I am aware) that\nthis is the way the git documentation should be read.\n\nSince, in this regard, it differs from most software\ndocumentation, it ought itself to be documented,\nperhaps on the top-level git man page.\n\n-P.\n"},{"id":"176636","messageId":"CAMOZ1Bvn64q5sVfo2-ZhTSpBttpjG1pHELJMM9sEmWsrqANCkw@mail.gmail.com","threadId":"28288","inReplyTo":"loom.20111001T073652-884@post.gmane.org","subject":"Re: [PATCH] Clarify that '--tags' fetches tags only","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-10-01T14:11:39Z","receivedAt":"2011-10-01T14:11:39Z","isPatch":true,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Sat, Oct 1, 2011 at 05:40, Peter Shenkin wrote:\n> Michael Witten gmail.com> writes:\n>> Well, you're missing the fact that it not only causes those to\n>> be downloaded, but it also causes the defaults to be ignored,\n>> which is why you don't get the other stuff. You can still tell\n>> git to fetch anything else you want in addition.\n>\n> I was no longer missing it at the time I posted.\n>\n> But that is indeed what I was missing when I first encountered\n> the behavior. The purpose of posting was to point out that\n> with  a very small change in the documentation,  I would not\n> have missed it.\n\nHowever, my point was this:\n\n You can still tell git to fetch anything else you want in addition.\n\nThat point doesn't seem clear with your proposed alteration.\n"},{"id":"176650","messageId":"loom.20111001T191413-25@post.gmane.org","threadId":"28288","inReplyTo":"CAMOZ1Bvn64q5sVfo2-ZhTSpBttpjG1pHELJMM9sEmWsrqANCkw@mail.gmail.com","subject":"Re: [PATCH] Clarify that '--tags' fetches tags only","fromName":"Peter Shenkin","fromEmail":"shenkin@gmail.com","sentAt":"2011-10-01T17:16:44Z","receivedAt":"2011-10-01T17:16:44Z","isPatch":true,"sender":{"key":"shenkin@gmail.com","avatar":"https://gravatar.com/avatar/52c52505b22c13500ceea15fda29f915e9968be9f67a9e4ee2a1721fc18a56e6?d=mp&s=160"},"body":"Michael Witten gmail.com> writes:\n> However, my point was this:\n> \n> You can still tell git to fetch anything else you want in addition.\n\nMichael,\n\nYes, you are right. I am still missing how to do that.\n\nCan you show me a sample fetch invocation that would\nhave the effect of downloading all tags and also branch heads?\n\nThanks,\n-P.\n"},{"id":"176652","messageId":"CAMOZ1Bsc2idQnKxeggruPi1rrY3+vsa=DoMydHY4+BM+qoW69w@mail.gmail.com","threadId":"28288","inReplyTo":"loom.20111001T191413-25@post.gmane.org","subject":"Re: [PATCH] Clarify that '--tags' fetches tags only","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-10-01T18:45:38Z","receivedAt":"2011-10-01T18:45:38Z","isPatch":true,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Sat, Oct 1, 2011 at 17:16, Peter Shenkin wrote:\n> Michael Witten gmail.com> writes:\n>> However, my point was this:\n>>\n>>   You can still tell git to fetch anything else you want in addition.\n>\n> Michael,\n>\n> Yes, you are right. I am still missing how to do that.\n>\n> Can you show me a sample fetch invocation that would\n> have the effect of downloading all tags and also branch heads?\n\nUnfortunately, there's currently no way to tell \"git fetch\" to\ndownload whatever your configuration files specify as default, but you\ncan at least be explicit by using what's called a \"refspec\" (which is\ndocumented in \"git help fetch\"):\n\n git fetch --tags origin '+refs/heads/*:refs/remotes/origin/*'\n\nYou could probably get your hands on the default refspec by rigging\nsomething up with \"git symbolic-ref\" and \"git config\", but that's so\nmuch hassle; currently, it is probably best just to run \"git fetch\"\ntwice.\n\nSincerely,\nMichael Witten\n\nYou might also find this email insightful:\n\n http://article.gmane.org/gmane.comp.version-control.git/181911\n Message-ID: <7142366f54c44cea82542adf8aea5bb9-mfwitten@gmail.com>\n Subject: Re: any way to \"re-sync\" a bare repository against\n another bare repository?\n"},{"id":"176657","messageId":"loom.20111001T214551-834@post.gmane.org","threadId":"28288","inReplyTo":"CAMOZ1Bsc2idQnKxeggruPi1rrY3+vsa=DoMydHY4+BM+qoW69w@mail.gmail.com","subject":"Re: [PATCH] Clarify that '--tags' fetches tags only","fromName":"Peter Shenkin","fromEmail":"shenkin@gmail.com","sentAt":"2011-10-01T20:22:16Z","receivedAt":"2011-10-01T20:22:16Z","isPatch":true,"sender":{"key":"shenkin@gmail.com","avatar":"https://gravatar.com/avatar/52c52505b22c13500ceea15fda29f915e9968be9f67a9e4ee2a1721fc18a56e6?d=mp&s=160"},"body":"Michael Witten gmail.com> writes:\n> git fetch --tags origin '+refs/heads/*:refs/remotes/origin/*'\n\nWell, Junio had just about convinced me that there was\nnothing wrong with the documentation -- just with the\nway I was reading it -- until I read the above.\n\nI tried it and yes, it does do what I want. Which was not\nat all my expectation, having read Junio's comment about\nhow the documentation is to be read.\n\nJunio argued that the man-page mod I suggested -- \nnamely, \"This flag causes all tags and their associated\nobjects (only) to be downloaded.\" -- was unneeded \nbecause the meaning, though correct, is clear already and\ntherefore redundant.\n\nBut the real problem is that the reading he gives is just\nwrong.\n\nI have the following in my .git/config file:\n\n[remote \"origin\"]\n\tfetch = +refs/heads/*:refs/remotes/origin/*\n\ttagopt = --tags\n\turl = \n\nGiven this, I do not see how anyone could infer from \nanything in the documentation that\n\ngit fetch\n\nwould do anything different from:\n\ngit fetch --tags origin +refs/heads/*:refs/remotes/origin/*\n\nIf I am wrong about this, please cite chapter and verse.\n\nThe question is not how the --tags option should be\ndocumented, but rather why \"--tags\" should behave\ndifferently when the refspec is given on the commandline\nthan when the refspec is given in the .git/config file.\n\nIn fact, I no longer think it is a documentation error. It\nis a just a really terrible implementation decision. If it\nwas desired to allow \"git fetch --tags\" to work without\nusing the user's specified refspec, then a \"--no-heads\"\noption should have been provided to override the user's\nrefspec -- no matter where it was given.\n\nThough a retrofit would likely break too many workflows,\nthe best one might hope for now would likely be the\naddition of a \"--heads\" option, which would have the\neffect of bringing down the branch heads even though\nthis would not normally be done.\" \n\nBut then it would still be necessary to say that \"--tags\"\ndoes not normally obey the user's refspec if given in the\nconfig file, but does if given on the command line. \n\nI might still be missing something. If anyone thinks the\ncurrent behavior is clear from a careful reading of the\ndocumentation, I would like to hear how that inference\ncould be drawn. For no matter how one reads the --tags\ndescription, it seems it is wrong in one of the two cases.\n\nIt is either wrong for a refspec on the command-line (if\nyou think it says it downloads tags only) or else it is wrong\nfor refspec in the config file (if you think it says it downloads\ntags and heads).\n"},{"id":"176659","messageId":"CAMOZ1BsYYmH6hqcB4vfCq2LAu+fxJ4MzPQ1+-erUSqU1ptx2mQ@mail.gmail.com","threadId":"28288","inReplyTo":"loom.20111001T214551-834@post.gmane.org","subject":"Re: [PATCH] Clarify that '--tags' fetches tags only","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-10-01T20:56:59Z","receivedAt":"2011-10-01T20:56:59Z","isPatch":true,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Sat, Oct 1, 2011 at 20:22, Peter Shenkin wrote:\n>\n> The question is not how the --tags option should be\n> documented, but rather why \"--tags\" should behave\n> differently when the refspec is given on the commandline\n> than when the refspec is given in the .git/config file.\n\nAgain, see here:\n\n [PATCH v3] Docs: Clarify the --tags option of `git fetch'\n Message-ID: <686c38876d5a4ad6bfac67ca77fe9bb3-mfwitten@gmail.com>\n http://article.gmane.org/gmane.comp.version-control.git/181887\n\nnamely:\n\n This option is merely a shorthand for writing the refspec\n `refs/tags/\\*:refs/tags/\\*'; that is,\n\n git fetch origin --tags\n git fetch origin --tags frotz\n\n are equivalent to:\n\n git fetch origin 'refs/tags/*:refs/tags/*'\n git fetch origin frotz 'refs/tags/*:refs/tags/*'\n\nIn other words, by writing \"--tags\", you are actually writing\n\"refs/tags/\\*:refs/tags/\\*\"; because you are stating an *explicit*\nrefspec, \"git fetch\" doesn't bother with any *implicit* default\nin your config, which is consistent with how \"git fetch\" works.\n\nIt would probably be a good idea if there were a \"--defaults\", too.\n"},{"id":"176661","messageId":"loom.20111001T232414-84@post.gmane.org","threadId":"28288","inReplyTo":"CAMOZ1BsYYmH6hqcB4vfCq2LAu+fxJ4MzPQ1+-erUSqU1ptx2mQ@mail.gmail.com","subject":"Re: [PATCH] Clarify that '--tags' fetches tags only","fromName":"Peter Shenkin","fromEmail":"shenkin@gmail.com","sentAt":"2011-10-01T21:41:09Z","receivedAt":"2011-10-01T21:41:09Z","isPatch":true,"sender":{"key":"shenkin@gmail.com","avatar":"https://gravatar.com/avatar/52c52505b22c13500ceea15fda29f915e9968be9f67a9e4ee2a1721fc18a56e6?d=mp&s=160"},"body":"Michael Witten gmail.com> writes:\n \n> On Sat, Oct 1, 2011 at 20:22, Peter Shenkin gmail.com> wrote:\n> [--tags] is merely a shorthand for writing the refspec\n> `refs/tags/\\*:refs/tags/\\*'; that is,\n\nYes, I understand that fully and it makes perfect sense.\n\nBut it leaves unexplained and undocumented the fact\nthat the user's specification of an *additional* refspec is\nobserved if the additional refspec is given on the\ncommand line but ignored if the additional refspec is\ngiven in the config file.\n\n-P.\n"},{"id":"176663","messageId":"loom.20111002T000048-827@post.gmane.org","threadId":"28288","inReplyTo":"loom.20111001T232414-84@post.gmane.org","subject":"Re: [PATCH] Clarify that '--tags' fetches tags only","fromName":"Peter Shenkin","fromEmail":"shenkin@gmail.com","sentAt":"2011-10-01T22:06:53Z","receivedAt":"2011-10-01T22:06:53Z","isPatch":true,"sender":{"key":"shenkin@gmail.com","avatar":"https://gravatar.com/avatar/52c52505b22c13500ceea15fda29f915e9968be9f67a9e4ee2a1721fc18a56e6?d=mp&s=160"},"body":"Peter Shenkin gmail.com> writes:\n> But it leaves unexplained and undocumented the fact\n> that the user's specification of an *additional* refspec is\n> observed if the additional refspec is given on the\n> command line but ignored if the additional refspec is\n> given in the config file.\n\nI have to take this back. It makes sense that a refspec on\nthe cmdline overrides one in the config file.\n\nI understand the behavior now, and Michael's suggestion of a\n--default to add the refspec in the config file to the cmdline\nis IMO a good one.\n\n'Nuff said. (By me, anyway....)\n\nThanks for your help and patience, everyone.\n\n-P.\n"}]}