{"thread":{"id":"12689","subject":"git remote --mirror bug?","startedAt":"2008-03-14T13:05:56Z","lastAt":"2008-03-31T03:03:21Z","messageCount":16,"participants":["Joakim Tjernlund","Junio C Hamano","Teemu Likonen","Daniel Barkalow","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"72075","messageId":"1205499956.7589.4.camel@gentoo-jocke.transmode.se","threadId":"12689","inReplyTo":null,"subject":"git remote --mirror bug?","fromName":"Joakim Tjernlund","fromEmail":"joakim.tjernlund@transmode.se","sentAt":"2008-03-14T13:05:56Z","receivedAt":"2008-03-14T13:05:56Z","isPatch":false,"sender":{"key":"joakim.tjernlund@transmode.se","avatar":null},"body":"Created a mirror like so:\n git --bare init \n git remote add --mirror os2kernel /usr/local/src/os2kernel\n\nGit fetch errors out\n git fetch os2kernel \nfatal: * refusing to create funny ref 'refs/stash' locally\n\nAlso \ngit remote show os2kernel \n* remote os2kernel\n  URL: /usr/local/src/os2kernel\nWarning: unrecognized mapping in remotes.os2kernel.fetch: +refs/*:refs/*\n\ngit --version\ngit version 1.5.4.3\n\n Jocke\n"},{"id":"72190","messageId":"1205604534.7589.20.camel@gentoo-jocke.transmode.se","threadId":"12689","inReplyTo":"1205499956.7589.4.camel@gentoo-jocke.transmode.se","subject":"Re: git remote --mirror bug?","fromName":"Joakim Tjernlund","fromEmail":"joakim.tjernlund@transmode.se","sentAt":"2008-03-15T18:08:53Z","receivedAt":"2008-03-15T18:08:53Z","isPatch":false,"sender":{"key":"joakim.tjernlund@transmode.se","avatar":null},"body":"\nOn Fri, 2008-03-14 at 14:05 +0100, Joakim Tjernlund wrote:\n> Created a mirror like so:\n>  git --bare init \n>  git remote add --mirror os2kernel /usr/local/src/os2kernel\n> \n> Git fetch errors out\n>  git fetch os2kernel \n> fatal: * refusing to create funny ref 'refs/stash' locally\n> \n> Also \n> git remote show os2kernel \n> * remote os2kernel\n>   URL: /usr/local/src/os2kernel\n> Warning: unrecognized mapping in remotes.os2kernel.fetch: +refs/*:refs/*\n> \n> git --version\n> git version 1.5.4.3\n> \n>  Jocke\n\nForgot to mention that clearing the stash with \"git stash clear\"\ndeletes the refs/stash file and then above commands succeeds.\n\nThis is a rather harmless bug, but if you are running the fetch command\nin a cron job to backup your repo, it becomes more serious as one\nwill not see the failure.\n\n Jocke\n"},{"id":"72214","messageId":"7v1w6bj7f9.fsf_-_@gitster.siamese.dyndns.org","threadId":"12689","inReplyTo":"1205604534.7589.20.camel@gentoo-jocke.transmode.se","subject":"Re* git remote --mirror bug?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-16T10:21:30Z","receivedAt":"2008-03-16T10:21:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Joakim Tjernlund <joakim.tjernlund@transmode.se> writes:\n\n>> git remote show os2kernel \n>> * remote os2kernel\n>>   URL: /usr/local/src/os2kernel\n>> Warning: unrecognized mapping in remotes.os2kernel.fetch: +refs/*:refs/*\n\nThis is very unfortunate.  What's more unfortunate is that, adding insult\nto injury, \"git remote\" reimplemented in C gives even worse nonsense:\n\n    $ git remote show git.git\n    fatal: * refusing to create funny ref 'refs/stash' locally\n\nThis is with my test repository sitting next to my primary git.git\nrepository with config entries like this:\n\n    [remote \"git.git\"]\n        url = ../git.git/\n        fetch = refs/*:refs/*\n\nThe thing is that we obviously are _not_ attempting to create anything\nwhen we say \"git remote show\".\n\nNow, it happens that \"stash\" is purely a local matter, and propagating it\nwith fetch (even with mirroring) may not make much sense.  Even if the\nmirroring is for backup purposes, its value is dubious (if you are backing\nup because you are afraid of disk failure, you should back up properly\nwith disk back-up tools).\n\nSo in that sense, it could be argued that it is Ok not to propagate\nrefs/stash and that was partly the reason why we create the \"stash\" ref\ndirectly underneath refs/ namespace.  Everything else that is propagatable\nhas at least two level refnames, e.g. heads/master, tags/v1.5.0, and the\nplumbing layer has a way to enforce this, and \"git remote\" uses it.\n\nBut that is not an excuse to fail \"git fetch\" (which is the underlying\nmechanism \"git remote\" uses).\n\nI think this patch may work the issue around for recent enough git, but\nI have to say that this is an interim fix.  With this, now you get a less\nnonsense output, but it still is nonsense nevertheless:\n\n    $ git remote show git.git\n    * remote git.git\n      URL: ../git.git/\n      New remote branch (next fetch will store in remotes/git.git)\n        refs/stash\n      Tracked remote branches\n        ar/sgid-bsd cb/mergetool cc/help cr/reset-parseopt db/diff...\n\nNotice that it talks about storing refs/stash in remotes/git.git?\n\nIt won't, and it shouldn't, as we told it to mirror refs/stash to\nrefs/stash.\n\nAs a side note, I think remote, when doing \"show\" that does _not_ update\nthe local side of tracking refs, should tweak the error behaviour that it\ncan trigger when it calls get_fetch_map().  The callee may have originally\nbeen written for \"fetch\" and had a hardcoded \"we are fetching and storing,\nso our behaviour when seeing a funny ref is to error out with \"refusing to\ncreate\" message and that is fine\" mentality.  Calling such a function when\nit is not actually fetching, without modifying the callee's assumption to\nsuit the error behaviour for its needs, is sloppy and needs to be fixed.\n\nThe scripted version if git-parse-remote, which is being phased out (it\nstill is used somewhat by git-pull and git-clone) has similar logic to\nparse fetch refspec mapping, but it does not understand the mirroring\nlayout (refs/*:refs/*) as you saw, so it fails way before it triggers\nthese issues.  What the C reimplementation does (or at least tries to do)\nis an improvement in that sense, but because it is relatively a new\nfeature, bugs in there are to be expected.\n\nWe are going into 1.5.5-rc feature freeze tonight, and squashing these\nbugs now are of the highest priority.  Please keep the bug reports and\nfixes flowing.\n\nThanks.\n\n---\n\n builtin-check-ref-format.c |    2 +-\n git-parse-remote.sh        |    9 +++++++--\n remote.c                   |   16 +++++++++++++---\n 3 files changed, 21 insertions(+), 6 deletions(-)\n\ndiff --git a/builtin-check-ref-format.c b/builtin-check-ref-format.c\nindex fe04be7..e2b4eef 100644\n--- a/builtin-check-ref-format.c\n+++ b/builtin-check-ref-format.c\n@@ -10,5 +10,5 @@ int cmd_check_ref_format(int argc, const char **argv, const char *prefix)\n {\n \tif (argc != 2)\n \t\tusage(\"git-check-ref-format refname\");\n-\treturn !!check_ref_format(argv[1]);\n+\treturn (-check_ref_format(argv[1]));\n }\ndiff --git a/git-parse-remote.sh b/git-parse-remote.sh\nindex 695a409..19d00e7 100755\n--- a/git-parse-remote.sh\n+++ b/git-parse-remote.sh\n@@ -156,8 +156,13 @@ canon_refs_list_for_fetch () {\n \n \t\tif local_ref_name=$(expr \"z$local\" : 'zrefs/\\(.*\\)')\n \t\tthen\n-\t\t   git check-ref-format \"$local_ref_name\" ||\n-\t\t   die \"* refusing to create funny ref '$local_ref_name' locally\"\n+\t\t   git check-ref-format \"$local_ref_name\"\n+\t\t   case \"$?\" in\n+\t\t   0 | 2) ;;\n+\t\t   *)\n+\t\t\tdie \"* refusing to create funny ref '$local_ref_name' locally\"\n+\t\t\t;;\n+\t\t   esac\n \t\tfi\n \t\techo \"${dot_prefix}${force}${remote}:${local}\"\n \tdone\ndiff --git a/remote.c b/remote.c\nindex f3f7375..6a95b1e 100644\n--- a/remote.c\n+++ b/remote.c\n@@ -1007,9 +1007,19 @@ int get_fetch_map(const struct ref *remote_refs,\n \t}\n \n \tfor (rm = ref_map; rm; rm = rm->next) {\n-\t\tif (rm->peer_ref && check_ref_format(rm->peer_ref->name + 5))\n-\t\t\tdie(\"* refusing to create funny ref '%s' locally\",\n-\t\t\t    rm->peer_ref->name);\n+\t\tif (rm->peer_ref) {\n+\t\t\tswitch (check_ref_format(rm->peer_ref->name + 5)) {\n+\t\t\tdefault:\n+\t\t\t\tdie(\"* refusing to create funny ref '%s' locally\",\n+\t\t\t\t    rm->peer_ref->name);\n+\t\t\t\tbreak;\n+\t\t\tcase CHECK_REF_FORMAT_ONELEVEL:\n+\t\t\t\t/* allow \"refs/stash\" to be propagated */\n+\t\t\t\tbreak;\n+\t\t\tcase CHECK_REF_FORMAT_OK:\n+\t\t\t\tbreak;\n+\t\t\t}\n+\t\t}\n \t}\n \n \tif (ref_map)\n"},{"id":"72222","messageId":"200803161921.49274.tlikonen@iki.fi","threadId":"12689","inReplyTo":"7v1w6bj7f9.fsf_-_@gitster.siamese.dyndns.org","subject":"remote/clone bug: Stale tracking branch HEAD","fromName":"Teemu Likonen","fromEmail":"tlikonen@iki.fi","sentAt":"2008-03-16T17:21:49Z","receivedAt":"2008-03-16T17:21:49Z","isPatch":false,"sender":{"key":"tlikonen@iki.fi","avatar":null},"body":"Junio C Hamano kirjoitti:\n\n> We are going into 1.5.5-rc feature freeze tonight, and squashing\n> these bugs now are of the highest priority.  Please keep the bug\n> reports and fixes flowing.\n\nI hope this bug won't find it's way to the release:\n\nhttp://article.gmane.org/gmane.comp.version-control.git/77188\n\n\nIn short: After 'git clone' the command 'git remote show origin' shows a \nstale tracking branch HEAD:\n\n  Stale tracking branch (use 'git remote prune')\n      HEAD\n\n'git remote prune origin' removes branch 'master'; you can see this \nwith \"git remote show origin\":\n\n  New remote branch (next fetch will store in remotes/origin)\n      master\n\n'git fetch' fetches 'master' again but the stale tracking branch HEAD \nappears again.\n"},{"id":"72248","messageId":"7v8x0igvdp.fsf_-_@gitster.siamese.dyndns.org","threadId":"12689","inReplyTo":"200803161921.49274.tlikonen@iki.fi","subject":"On fetch refspecs and wildcards","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-16T22:24:34Z","receivedAt":"2008-03-16T22:24:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I was looking at t5505 tests and noticed something funny.\n\nThis is a design level question, so I am cc'ing Daniel whose remote.c is\nheavily involved in the new implementation.\n\nWhat should this config do:\n\n    [remote \"origin\"]\n        url = ../one/.git\n        fetch = +refs/heads/*:refs/remotes/origin/*\n        fetch = refs/heads/master:refs/heads/upstream\n\nwhen the other repository (../one/.git) has branches \"master\" and \"side2\"?\n\nI am not sure if the original implementation used to copy master to both\nrefs/remotes/origin/master and refs/heads/upstream, but I think that is\nwhat the users would expect.  \n\nI think the current one excludes any source that has an explicit\ndestination from the wildcard matches.  It is probably Ok as long as we\nreject if the same source has more than one destinations (or matches more\nthan one wildcards, for that matter) like this as a configuration error:\n\n    [remote \"origin\"]\n        url = ../one/.git\n        fetch = refs/heads/master:refs/heads/upstream\n        fetch = refs/heads/master:refs/heads/another\n\nIf it doesn't, it does feel somewhat inconsistent.\n\nFortunately or unfortunately, Documentation/pull-fetch-param.txt does not\ntalk about wildcard refspecs (not even the syntax, let alone the\nsemantics), so we can define whatever we want right now, and I think both\n\n    (1) allow duplicated destinations, including wildcard matches; and\n\n    (2) refuse duplicated destinations for explicit ones, and more than\n        one wildcard patterns that match the same ref, but omit explicitly\n        specified ones from wildcard matches;\n\nare viable options.  I suspect the current code does not do either.  We\nshould pick one semantics, make sure the implementation matches that, and\ndocument it.\n\nAnother topic is what the semantics should be for mirroring configuration,\nlike this:\n\n    [remote \"origin\"]\n        url = ../one/.git\n        fetch = refs/*:refs/*\n\nor\n\n    [remote \"origin\"]\n        url = ../one/.git\n        fetch = refs/*:refs/remotes/one/*\n\nThe issues are:\n\n (1) get_fetch_map() currently insists on refname to be check_ref_format()\n     clean; it even rejects CHECK_REF_FORMAT_ONELEVEL, which means that\n     refs/stash would not be considered Ok and the code will die().\n\n (2) \"git remote prune\" seems to cull refs/remotes/one/HEAD if exists.\n\nCurrently we do not have a way to determine where HEAD at the remote\npoints at at the protocol level (I've sent a patch to the list earlier for\nthe necessary protocol extension on the upload-pack side, but receiver\nside never got implemented in remotes.c).  So we cannot propagate\nrefs/HEAD information correctly right now, but when we accept the protocol\nextension to do so, issue (1) will matter also for HEAD.\n\nI think there is no design level question on this one.  I think both are\nbugs we currently have (and they may probably not be regressions).\n"},{"id":"72251","messageId":"7vve3mfgf2.fsf@gitster.siamese.dyndns.org","threadId":"12689","inReplyTo":"7v8x0igvdp.fsf_-_@gitster.siamese.dyndns.org","subject":"Re: On fetch refspecs and wildcards","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-16T22:33:05Z","receivedAt":"2008-03-16T22:33:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> ...\n> Fortunately or unfortunately, Documentation/pull-fetch-param.txt does not\n> talk about wildcard refspecs (not even the syntax, let alone the\n> semantics), so we can define whatever we want right now, and I think both\n>\n>     (1) allow duplicated destinations, including wildcard matches; and\n\nClarification.\n\n\"s/;/, but do honor requests to copy one thing to multiple destinations;/\"\nis what I meant here.\n\n>     (2) refuse duplicated destinations for explicit ones, and more than\n>         one wildcard patterns that match the same ref, but omit explicitly\n>         specified ones from wildcard matches;\n>\n> are viable options.  I suspect the current code does not do either.  We\n> should pick one semantics, make sure the implementation matches that, and\n> document it.\n"},{"id":"72255","messageId":"alpine.LNX.1.00.0803161831330.19665@iabervon.org","threadId":"12689","inReplyTo":"7v8x0igvdp.fsf_-_@gitster.siamese.dyndns.org","subject":"Re: On fetch refspecs and wildcards","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-03-16T23:03:14Z","receivedAt":"2008-03-16T23:03:14Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 16 Mar 2008, Junio C Hamano wrote:\n\n> I was looking at t5505 tests and noticed something funny.\n> \n> This is a design level question, so I am cc'ing Daniel whose remote.c is\n> heavily involved in the new implementation.\n> \n> What should this config do:\n> \n>     [remote \"origin\"]\n>         url = ../one/.git\n>         fetch = +refs/heads/*:refs/remotes/origin/*\n>         fetch = refs/heads/master:refs/heads/upstream\n> \n> when the other repository (../one/.git) has branches \"master\" and \"side2\"?\n> \n> I am not sure if the original implementation used to copy master to both\n> refs/remotes/origin/master and refs/heads/upstream, but I think that is\n> what the users would expect.  \n> \n> I think the current one excludes any source that has an explicit\n> destination from the wildcard matches.  It is probably Ok as long as we\n> reject if the same source has more than one destinations (or matches more\n> than one wildcards, for that matter) like this as a configuration error:\n> \n>     [remote \"origin\"]\n>         url = ../one/.git\n>         fetch = refs/heads/master:refs/heads/upstream\n>         fetch = refs/heads/master:refs/heads/another\n> \n> If it doesn't, it does feel somewhat inconsistent.\n> \n> Fortunately or unfortunately, Documentation/pull-fetch-param.txt does not\n> talk about wildcard refspecs (not even the syntax, let alone the\n> semantics), so we can define whatever we want right now, and I think both\n> \n>     (1) allow duplicated destinations, including wildcard matches; and\n> \n>     (2) refuse duplicated destinations for explicit ones, and more than\n>         one wildcard patterns that match the same ref, but omit explicitly\n>         specified ones from wildcard matches;\n> \n> are viable options.  I suspect the current code does not do either.  We\n> should pick one semantics, make sure the implementation matches that, and\n> document it.\n\nActually, I think the current code is close to (2). get_fetch_map() \nreturns everything, ref_remove_duplicates() removes any exact matches and \ngives errors if there's the same destination for two different sources.\n\n(Upon further consideration, there's one slight issue:\n\n[remote \"origin\"]\n\tfetch = refs/heads/*:refs/remotes/origin/*\n\tfetch = +refs/heads/pu:refs/remotes/origin/pu\n\nis not quite the same as:\n\n[remote \"origin\"]\n\tfetch = +refs/heads/pu:refs/remotes/origin/pu\n\tfetch = refs/heads/*:refs/remotes/origin/*\n\nin whether pu will be forced; the forcing flag on the first matching \nrefspec is what matters.)\n\nIn any case, the implementation should be easy enough with any of these \ncombinations.\n\n> Another topic is what the semantics should be for mirroring configuration,\n> like this:\n> \n>     [remote \"origin\"]\n>         url = ../one/.git\n>         fetch = refs/*:refs/*\n> \n> or\n> \n>     [remote \"origin\"]\n>         url = ../one/.git\n>         fetch = refs/*:refs/remotes/one/*\n> \n> The issues are:\n> \n>  (1) get_fetch_map() currently insists on refname to be check_ref_format()\n>      clean; it even rejects CHECK_REF_FORMAT_ONELEVEL, which means that\n>      refs/stash would not be considered Ok and the code will die().\n\nYes, that's probably wrong. We probably do want to reject people whose \nservers send us \"refs/heads/../../heads/master\", but not \"refs/stash\".\n\n>  (2) \"git remote prune\" seems to cull refs/remotes/one/HEAD if exists.\n> \n> Currently we do not have a way to determine where HEAD at the remote\n> points at at the protocol level (I've sent a patch to the list earlier for\n> the necessary protocol extension on the upload-pack side, but receiver\n> side never got implemented in remotes.c).  So we cannot propagate\n> refs/HEAD information correctly right now, but when we accept the protocol\n> extension to do so, issue (1) will matter also for HEAD.\n\nThere's the issue that \"HEAD\" isn't \"refs/HEAD\". I'm not at all sure how \nthe user should communicate the desire to update things to match the \nremote HEAD. FWIW, I was considering moving the code to guess where the \nremote HEAD points from builtin-clone to remotes.c, until I realized that \nit's not clear what configuration should control this. I think it'd be \nnecessary to have a special option to say \"write HEAD here\", but I may be \nwrong.\n\nThe implementation of whatever handles it is slightly non-trivial, since \nstruct ref can't currently represent a symref, but that shouldn't be a \nmajor issue.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"72259","messageId":"7v8x0idx6e.fsf@gitster.siamese.dyndns.org","threadId":"12689","inReplyTo":"alpine.LNX.1.00.0803161831330.19665@iabervon.org","subject":"Re: On fetch refspecs and wildcards","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-17T00:14:01Z","receivedAt":"2008-03-17T00:14:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow <barkalow@iabervon.org> writes:\n\n> On Sun, 16 Mar 2008, Junio C Hamano wrote:\n> ...\n>> Fortunately or unfortunately, Documentation/pull-fetch-param.txt does not\n>> talk about wildcard refspecs (not even the syntax, let alone the\n>> semantics), so we can define whatever we want right now, and I think both\n>> \n>>     (1) allow duplicated destinations, including wildcard matches; and\n>> \n>>     (2) refuse duplicated destinations for explicit ones, and more than\n>>         one wildcard patterns that match the same ref, but omit explicitly\n>>         specified ones from wildcard matches;\n>> \n>> are viable options.  I suspect the current code does not do either.  We\n>> should pick one semantics, make sure the implementation matches that, and\n>> document it.\n>\n> Actually, I think the current code is close to (2). get_fetch_map() \n> returns everything, ref_remove_duplicates() removes any exact matches and \n> gives errors if there's the same destination for two different sources.\n>\n> (Upon further consideration, there's one slight issue:\n>\n> [remote \"origin\"]\n> \tfetch = refs/heads/*:refs/remotes/origin/*\n> \tfetch = +refs/heads/pu:refs/remotes/origin/pu\n>\n> is not quite the same as:\n>\n> [remote \"origin\"]\n> \tfetch = +refs/heads/pu:refs/remotes/origin/pu\n> \tfetch = refs/heads/*:refs/remotes/origin/*\n>\n> in whether pu will be forced; the forcing flag on the first matching \n> refspec is what matters.)\n\nOk.\n\nAs I said, I think either one is valid, and I only mentioned (1) because I\nthought refusing duplicates might be more work to get it right.  So if\nyour code does _most of_ (2), that is good.  Please document what it is\nmeant to do in Documentation/pull-fetch-param.txt, so that others can\nreport deviation from the defined semantics, if any, in the implementation\nfor us to fix.\n\n>> The issues are:\n>> \n>>  (1) get_fetch_map() currently insists on refname to be check_ref_format()\n>>      clean; it even rejects CHECK_REF_FORMAT_ONELEVEL, which means that\n>>      refs/stash would not be considered Ok and the code will die().\n>\n> Yes, that's probably wrong. We probably do want to reject people whose \n> servers send us \"refs/heads/../../heads/master\", but not \"refs/stash\".\n\nThe feeler patch I sent out would be Ok, then.  Can you test it, after\nupdating it with the die() -> error() and message rewording we discussed\nin the other message, and send the result in?\n\n>>  (2) \"git remote prune\" seems to cull refs/remotes/one/HEAD if exists.\n>> \n>> Currently we do not have a way to determine where HEAD at the remote\n>> points at at the protocol level (I've sent a patch to the list earlier for\n>> the necessary protocol extension on the upload-pack side, but receiver\n>> side never got implemented in remotes.c).  So we cannot propagate\n>> refs/HEAD information correctly right now, but when we accept the protocol\n>> extension to do so, issue (1) will matter also for HEAD.\n>\n> There's the issue that \"HEAD\" isn't \"refs/HEAD\". I'm not at all sure how \n> the user should communicate the desire to update things to match the \n> remote HEAD. FWIW, I was considering moving the code to guess where the \n> remote HEAD points from builtin-clone to remotes.c, until I realized that \n> it's not clear what configuration should control this.. I think it'd be \n> necessary to have a special option to say \"write HEAD here\", but I may be \n> wrong.\n\nI tend to agree.  I'd propose the semantics for refs/remotes/<name>/HEAD\nsymref to be like this:\n\n * It is under _local_ control.  That means fetch should not update it, and\n   \"remote prune\" should not prune it, nor even mention it is prunable.\n\n * It is the means for the user (i.e. the owner of the local repository)\n   to express which branch from the remote he is most interested in.\n   I.e., it exists solely to make \"<name>\" => \"refs/remotes/<name>/HEAD\"\n   ref dwimming work as expected.\n\n * It is set up by \"git clone\" to point at the branch the remote had its\n   HEAD pointing at when clone happened but that is merely a convenience\n   feature.\n\n * We would probably want an explicit convenience subcommand \"git remote\n   something <name> <branch>\" that switches refs/remotes/<name>/HEAD to\n   point at a specific remote tracking branch, although you can do that\n   yourself with symbolic-ref.\n\n * We may want to teach \"git remote add <name>\" to do the same HEAD\n   discovery as done by \"git clone\" (earlier JBF had a patch for it to the\n   scripted version), to have the same convenience feature as \"git clone\"\n   has.\n\n * If we teach \"git remote add\" to set refs/remotes/<name>/HEAD, we may\n   also want to teach it an explicit way to let the user say \"I want\n   <name> to mean refs/remotes/<name>/this\", not whatever the remote side\n   currently points at with its HEAD.\n\n * If we teach \"git remote add\" to do the HEAD discovery, we may also want\n   to teach \"git remote update\" a way to let the user request \"my\n   refs/remotes/<name>/HEAD may not be pointing at the branch the remote\n   currently points at with its HEAD.  Please update mine to match\n   theirs\".\n\nWhen true mirroring configuration \"refs/*:refs/*\" is employed, neither\n\"refs/HEAD\" nor \"refs/heads/HEAD\" is needed nor desired on the local side.\n"},{"id":"72267","messageId":"alpine.LNX.1.00.0803162124200.19665@iabervon.org","threadId":"12689","inReplyTo":"7v8x0idx6e.fsf@gitster.siamese.dyndns.org","subject":"Re: On fetch refspecs and wildcards","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-03-17T02:14:13Z","receivedAt":"2008-03-17T02:14:13Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 16 Mar 2008, Junio C Hamano wrote:\n\n> Daniel Barkalow <barkalow@iabervon.org> writes:\n> \n> > On Sun, 16 Mar 2008, Junio C Hamano wrote:\n> > ...\n> >> Fortunately or unfortunately, Documentation/pull-fetch-param.txt does not\n> >> talk about wildcard refspecs (not even the syntax, let alone the\n> >> semantics), so we can define whatever we want right now, and I think both\n> >> \n> >>     (1) allow duplicated destinations, including wildcard matches; and\n> >> \n> >>     (2) refuse duplicated destinations for explicit ones, and more than\n> >>         one wildcard patterns that match the same ref, but omit explicitly\n> >>         specified ones from wildcard matches;\n> >> \n> >> are viable options.  I suspect the current code does not do either.  We\n> >> should pick one semantics, make sure the implementation matches that, and\n> >> document it.\n> >\n> > Actually, I think the current code is close to (2). get_fetch_map() \n> > returns everything, ref_remove_duplicates() removes any exact matches and \n> > gives errors if there's the same destination for two different sources.\n> >\n> > (Upon further consideration, there's one slight issue:\n> >\n> > [remote \"origin\"]\n> > \tfetch = refs/heads/*:refs/remotes/origin/*\n> > \tfetch = +refs/heads/pu:refs/remotes/origin/pu\n> >\n> > is not quite the same as:\n> >\n> > [remote \"origin\"]\n> > \tfetch = +refs/heads/pu:refs/remotes/origin/pu\n> > \tfetch = refs/heads/*:refs/remotes/origin/*\n> >\n> > in whether pu will be forced; the forcing flag on the first matching \n> > refspec is what matters.)\n> \n> Ok.\n> \n> As I said, I think either one is valid, and I only mentioned (1) because I\n> thought refusing duplicates might be more work to get it right.  So if\n> your code does _most of_ (2), that is good.  Please document what it is\n> meant to do in Documentation/pull-fetch-param.txt, so that others can\n> report deviation from the defined semantics, if any, in the implementation\n> for us to fix.\n\nOh, sorry, I got the cases backwards. The current code does (1): for each \nrefspec, it collects all of the matches for that refspec into one big \nlist, and then it (a) removes items where src and dst match and (b) gives \nerrors if dst matches but src doesn't (which is obviously a problem: two \nrefspecs will try to write different things to the same place).\n\n> >> The issues are:\n> >> \n> >>  (1) get_fetch_map() currently insists on refname to be check_ref_format()\n> >>      clean; it even rejects CHECK_REF_FORMAT_ONELEVEL, which means that\n> >>      refs/stash would not be considered Ok and the code will die().\n> >\n> > Yes, that's probably wrong. We probably do want to reject people whose \n> > servers send us \"refs/heads/../../heads/master\", but not \"refs/stash\".\n> \n> The feeler patch I sent out would be Ok, then.  Can you test it, after\n> updating it with the die() -> error() and message rewording we discussed\n> in the other message, and send the result in?\n\nSure.\n\n> >>  (2) \"git remote prune\" seems to cull refs/remotes/one/HEAD if exists.\n> >> \n> >> Currently we do not have a way to determine where HEAD at the remote\n> >> points at at the protocol level (I've sent a patch to the list earlier for\n> >> the necessary protocol extension on the upload-pack side, but receiver\n> >> side never got implemented in remotes.c).  So we cannot propagate\n> >> refs/HEAD information correctly right now, but when we accept the protocol\n> >> extension to do so, issue (1) will matter also for HEAD.\n> >\n> > There's the issue that \"HEAD\" isn't \"refs/HEAD\". I'm not at all sure how \n> > the user should communicate the desire to update things to match the \n> > remote HEAD. FWIW, I was considering moving the code to guess where the \n> > remote HEAD points from builtin-clone to remotes.c, until I realized that \n> > it's not clear what configuration should control this.. I think it'd be \n> > necessary to have a special option to say \"write HEAD here\", but I may be \n> > wrong.\n> \n> I tend to agree.  I'd propose the semantics for refs/remotes/<name>/HEAD\n> symref to be like this:\n> \n>  * It is under _local_ control.  That means fetch should not update it, and\n>    \"remote prune\" should not prune it, nor even mention it is prunable.\n\nAh, interesting. Not at all what I'd expected, but much more useful, I \nthink, than having it controlled by the remote.\n\n>  * It is the means for the user (i.e. the owner of the local repository)\n>    to express which branch from the remote he is most interested in.\n>    I.e., it exists solely to make \"<name>\" => \"refs/remotes/<name>/HEAD\"\n>    ref dwimming work as expected.\n> \n>  * It is set up by \"git clone\" to point at the branch the remote had its\n>    HEAD pointing at when clone happened but that is merely a convenience\n>    feature.\n\nIn other words, a reasonable default since you haven't yet configured \nanything.\n\n>  * We would probably want an explicit convenience subcommand \"git remote\n>    something <name> <branch>\" that switches refs/remotes/<name>/HEAD to\n>    point at a specific remote tracking branch, although you can do that\n>    yourself with symbolic-ref.\n\nThe command would mainly be useful to users as a way of making it clear \nthat it's theirs to control, rather than as a method for controlling it.\n\n>  * We may want to teach \"git remote add <name>\" to do the same HEAD\n>    discovery as done by \"git clone\" (earlier JBF had a patch for it to the\n>    scripted version), to have the same convenience feature as \"git clone\"\n>    has.\n\nRight.\n\n>  * If we teach \"git remote add\" to set refs/remotes/<name>/HEAD, we may\n>    also want to teach it an explicit way to let the user say \"I want\n>    <name> to mean refs/remotes/<name>/this\", not whatever the remote side\n>    currently points at with its HEAD.\n\nAnd likewise clone, which is probably more relevant, actually, because \nclone will often also create a local branch based on it and check that \nout, which can waste some time if you actually want to use some other \nbranch.\n\n>  * If we teach \"git remote add\" to do the HEAD discovery, we may also want\n>    to teach \"git remote update\" a way to let the user request \"my\n>    refs/remotes/<name>/HEAD may not be pointing at the branch the remote\n>    currently points at with its HEAD.  Please update mine to match\n>    theirs\".\n\nRight.\n\n> When true mirroring configuration \"refs/*:refs/*\" is employed, neither\n> \"refs/HEAD\" nor \"refs/heads/HEAD\" is needed nor desired on the local side.\n\nSure.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"72356","messageId":"alpine.DEB.1.00.0803181503240.3200@eeepc-johanness","threadId":"12689","inReplyTo":"7v1w6bj7f9.fsf_-_@gitster.siamese.dyndns.org","subject":"Re: Re* git remote --mirror bug?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-18T14:04:15Z","receivedAt":"2008-03-18T14:04:15Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 16 Mar 2008, Junio C Hamano wrote:\n\n> Joakim Tjernlund <joakim.tjernlund@transmode.se> writes:\n> \n> >> git remote show os2kernel \n> >> * remote os2kernel\n> >>   URL: /usr/local/src/os2kernel\n> >> Warning: unrecognized mapping in remotes.os2kernel.fetch: +refs/*:refs/*\n> \n> This is very unfortunate.\n>\n> [...]\n>\n>  builtin-check-ref-format.c |    2 +-\n>  git-parse-remote.sh        |    9 +++++++--\n>  remote.c                   |   16 +++++++++++++---\n>  3 files changed, 21 insertions(+), 6 deletions(-)\n\nThanks for the fix, and sorry for not being available to fix it myself.\n\nCiao,\nDscho\n"},{"id":"72376","messageId":"7v4pb37t3w.fsf@gitster.siamese.dyndns.org","threadId":"12689","inReplyTo":"alpine.DEB.1.00.0803181503240.3200@eeepc-johanness","subject":"Re: Re* git remote --mirror bug?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-18T19:02:59Z","receivedAt":"2008-03-18T19:02:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> On Sun, 16 Mar 2008, Junio C Hamano wrote:\n>\n>> Joakim Tjernlund <joakim.tjernlund@transmode.se> writes:\n>> \n>> >> git remote show os2kernel \n>> >> * remote os2kernel\n>> >>   URL: /usr/local/src/os2kernel\n>> >> Warning: unrecognized mapping in remotes.os2kernel.fetch: +refs/*:refs/*\n>> \n>> This is very unfortunate.\n>>\n>> [...]\n>>\n>>  builtin-check-ref-format.c |    2 +-\n>>  git-parse-remote.sh        |    9 +++++++--\n>>  remote.c                   |   16 +++++++++++++---\n>>  3 files changed, 21 insertions(+), 6 deletions(-)\n>\n> Thanks for the fix,...\n\nAs I alluded to in the message, I do not think this was a fix.\n"},{"id":"72426","messageId":"alpine.DEB.1.00.0803190033070.2251@eeepc-johanness","threadId":"12689","inReplyTo":"7v4pb37t3w.fsf@gitster.siamese.dyndns.org","subject":"Re: Re* git remote --mirror bug?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-19T00:35:42Z","receivedAt":"2008-03-19T00:35:42Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 18 Mar 2008, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > On Sun, 16 Mar 2008, Junio C Hamano wrote:\n> >\n> >> Joakim Tjernlund <joakim.tjernlund@transmode.se> writes:\n> >> \n> >> >> git remote show os2kernel \n> >> >> * remote os2kernel\n> >> >>   URL: /usr/local/src/os2kernel\n> >> >> Warning: unrecognized mapping in remotes.os2kernel.fetch: +refs/*:refs/*\n> >> \n> >> This is very unfortunate.\n> >>\n> >> [...]\n> >>\n> >>  builtin-check-ref-format.c |    2 +-\n> >>  git-parse-remote.sh        |    9 +++++++--\n> >>  remote.c                   |   16 +++++++++++++---\n> >>  3 files changed, 21 insertions(+), 6 deletions(-)\n> >\n> > Thanks for the fix,...\n> \n> As I alluded to in the message, I do not think this was a fix.\n\nI am very sorry, as I read the mail under extreme time pressure, this must \nhave slipped by.  I hope that my time management reverts to normal \nbeginning tomorrow.\n\nI looked into this issue, and I seem not to be able to reproduce with my \ncurrent git (which is based on next).\n\nCiao,\nDscho\n"},{"id":"73238","messageId":"7vbq4z4bl1.fsf@gitster.siamese.dyndns.org","threadId":"12689","inReplyTo":"1205604534.7589.20.camel@gentoo-jocke.transmode.se","subject":"[PATCH/RFC] Allow \"git remote --mirror\" to mirror stashes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-28T06:16:58Z","receivedAt":"2008-03-28T06:16:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"When you have \"remote.$there.fetch = refs/*:refs/*\" and the remote has a\nref directly under refs/ (e.g. \"stash\"), \"git fetch\" still errored out\neven with fixes in -rc1.\n\nThis should hopefully fix it.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n\n * Rather than failing, it would be better to allow \"git fetch\" to succeed\n   by doing this, but on the other hand, stash is purely a local matter,\n   so it might make more sense to avoid exposing it from the uploader.\n\n builtin-fetch-pack.c |   13 ++++++++++---\n 1 files changed, 10 insertions(+), 3 deletions(-)\n\ndiff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c\nindex 65350ca..472bad5 100644\n--- a/builtin-fetch-pack.c\n+++ b/builtin-fetch-pack.c\n@@ -363,10 +363,17 @@ static void filter_refs(struct ref **refs, int nr_match, char **match)\n \t\treturn_refs = NULL;\n \n \tfor (ref = *refs; ref; ref = next) {\n+\t\tint trash = 0;\n+\n \t\tnext = ref->next;\n-\t\tif (!memcmp(ref->name, \"refs/\", 5) &&\n-\t\t    check_ref_format(ref->name + 5))\n-\t\t\t; /* trash */\n+\t\tif (!memcmp(ref->name, \"refs/\", 5)) {\n+\t\t\ttrash = check_ref_format(ref->name + 5);\n+\t\t\tif (trash == CHECK_REF_FORMAT_ONELEVEL)\n+\t\t\t\ttrash = 0;\n+\t\t}\n+\n+\t\tif (trash)\n+\t\t\t; /* this is trash */\n \t\telse if (args.fetch_all &&\n \t\t\t (!args.depth || prefixcmp(ref->name, \"refs/tags/\") )) {\n \t\t\t*newtail = ref;\n"},{"id":"73274","messageId":"alpine.LNX.1.00.0803281124240.19665@iabervon.org","threadId":"12689","inReplyTo":"7vbq4z4bl1.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH/RFC] Allow \"git remote --mirror\" to mirror stashes","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-03-28T15:45:43Z","receivedAt":"2008-03-28T15:45:43Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 27 Mar 2008, Junio C Hamano wrote:\n\n> When you have \"remote.$there.fetch = refs/*:refs/*\" and the remote has a\n> ref directly under refs/ (e.g. \"stash\"), \"git fetch\" still errored out\n> even with fixes in -rc1.\n\nIn particular, it would fail to request \"refs/stash\", and then be \nsurprised that it didn't get the object that points to. (This would be a \nhelpful thing to mention in the commit message)\n\n> This should hopefully fix it.\n\nMaybe it shouldn't do any filtering here, and instead do it in \ncmd_fetch_pack? If the transport code gets to this point and anything gets \nfiltered out by this function, the transport code or builtin-fetch will \nhave to be terribly confused and fail with a mysterious error message, \nAFAICT.\n\n>  * Rather than failing, it would be better to allow \"git fetch\" to succeed\n>    by doing this, but on the other hand, stash is purely a local matter,\n>    so it might make more sense to avoid exposing it from the uploader.\n\nThis is also true, although I'm not too sure that we won't want to do \nthings like having \"refs/default\" in a public repository be the \nrepository's suggestion for the default branch (to replace \"HEAD\", \nbecause, in a world where people use lots of branches, the \"current \nbranch\" idea and the \"default branch\" idea aren't really the same idea, \nalthough there's no technical conflict since only one of these ideas is \nreally important in any given repository). So we probably want a whitelist \nor blacklist for refs to serve when we avoid exposing things in the \nuploader, rather than using the level, in which case it's definitely \nimportant to have fetch-pack just ignore stuff.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"73388","messageId":"7vve33vj7a.fsf@gitster.siamese.dyndns.org","threadId":"12689","inReplyTo":"alpine.LNX.1.00.0803281124240.19665@iabervon.org","subject":"Re: [PATCH/RFC] Allow \"git remote --mirror\" to mirror stashes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-31T00:19:21Z","receivedAt":"2008-03-31T00:19:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow <barkalow@iabervon.org> writes:\n\n> On Thu, 27 Mar 2008, Junio C Hamano wrote:\n>\n> Maybe it shouldn't do any filtering here, and instead do it in \n> cmd_fetch_pack?\n\nI dunno.  How would the code look like?\n\n> This is also true, although I'm not too sure that we won't want to do \n> things like having \"refs/default\" in a public repository be the \n> repository's suggestion for the default branch (to replace \"HEAD\", \n> because, in a world where people use lots of branches, the \"current \n> branch\" idea and the \"default branch\" idea aren't really the same idea, \n\nIn a public repository with many branches to serve people with different\ninterests, I do not think a single refs/default in addition to HEAD would\nhelp that much.  We would _not_ want to have more magic refs like HEAD.\n\nQuite the opposite.  In such a repository, HEAD means even less, and\ninstead of giving an extra layer of indirection, you tell people which\nbranches are what in your repository.  \"If you are interested in only the\nbugfixes without any new features since the last feature lease no matter\nhow solid and tested they are, use 'maint' branch.  If you want solid and\ntested features, and do not mind new features, use 'master'.  Etc.\".\n\nAnd just like a good API names its functions sensibly, you give meaningful\nnames to your branches, so that you do not _need_ that extra layer of\nindirection refs/default would incur.\n"},{"id":"73398","messageId":"alpine.LNX.1.00.0803302239220.19665@iabervon.org","threadId":"12689","inReplyTo":"7vve33vj7a.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH/RFC] Allow \"git remote --mirror\" to mirror stashes","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-03-31T03:03:21Z","receivedAt":"2008-03-31T03:03:21Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 30 Mar 2008, Junio C Hamano wrote:\n\n> Daniel Barkalow <barkalow@iabervon.org> writes:\n> \n> > On Thu, 27 Mar 2008, Junio C Hamano wrote:\n> >\n> > Maybe it shouldn't do any filtering here, and instead do it in \n> > cmd_fetch_pack?\n> \n> I dunno.  How would the code look like?\n\nActually, I don't see any reason to call check_ref_format. The point of \nfilter_refs is to make sure that we don't fetch anything we didn't ask \nfor. We shouldn't care at all about the name of the refs we're considering \nexcept whether there's in the list to fetch, and if the user requests the \nobjects for a ref named 'refs/*^&+' and the server offers such a ref, \nthere's no reason for us not to get the objects. (Sure, we shouldn't \ncreate the ref with that name, but this code path doesn't go on the create \nrefs based on these names, except when it's already checking their format \nfor that purpose anyway.)\n\nSo I'd say just drop the first \"if\" in that sequence entirely. The only \nthing that could be a problem we'd want to stop here is something that \nwould break the packet protocol, and we've already gotten these values \nover the packet protocol anyway.\n\n> > This is also true, although I'm not too sure that we won't want to do \n> > things like having \"refs/default\" in a public repository be the \n> > repository's suggestion for the default branch (to replace \"HEAD\", \n> > because, in a world where people use lots of branches, the \"current \n> > branch\" idea and the \"default branch\" idea aren't really the same idea, \n> \n> In a public repository with many branches to serve people with different\n> interests, I do not think a single refs/default in addition to HEAD would\n> help that much.  We would _not_ want to have more magic refs like HEAD.\n> \n> Quite the opposite.  In such a repository, HEAD means even less, and\n> instead of giving an extra layer of indirection, you tell people which\n> branches are what in your repository.  \"If you are interested in only the\n> bugfixes without any new features since the last feature lease no matter\n> how solid and tested they are, use 'maint' branch.  If you want solid and\n> tested features, and do not mind new features, use 'master'.  Etc.\".\n\nIt's not a particularly *useful* default, but \"git-clone\" presumably \nshould initially check out *something* given a repository with multiple \nbranches and no local user guidance. And, if this is the git.git \nrepository, and you briefly check out each branch in turn to build it when \nyou push new changes, then HEAD is usually master but briefly, rarely, and \nirrelevantly other things.\n\nI'm not convinced that it's something worth actually implementing. But I \nthink it's a plausible enough idea that we shouldn't exclude the \npossibility of one-level public refs. There are various usues people find \nfor this sort of low-semantics pointer on FTP sites, so it could be useful \nin git as well.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"}]}