{"thread":{"id":"43096","subject":"Re: [PATCH] Do not ignore hidden refs","startedAt":"2006-11-18T04:11:37Z","lastAt":"2006-11-19T00:48:17Z","messageCount":14,"participants":["Petr Baudis","Junio C Hamano","Shawn Pearce","Linus Torvalds"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"294734","messageId":"20061118041137.6064.75827.stgit@machine.or.cz","threadId":"43096","inReplyTo":null,"subject":"[PATCH] Do not ignore hidden refs","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-18T04:11:37Z","receivedAt":"2006-11-18T04:11:37Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Some of the ref manipulation tools (git-for-each-ref and git-show-ref in\nparticular) would not handle hidden (~ /^\\./) refs. This may be an\nacceptable or possibly even desirable behaviour for the ref walkers and\nrepackers, but git-show-ref hiddenrefname must work.\n\nThis makes Git not ignore hidden refs at all. I'm not opposed to making\nsome particular parts of the ref interface to continue to ignore hidden\nrefs, but the restriction cannot be so deep.\n\nSigned-off-by: Petr Baudis \n---\n\n refs.c | 3 ++-\n 1 files changed, 2 insertions(+), 1 deletions(-)\n\ndiff --git a/refs.c b/refs.c\nindex f003a0b..06fa5c2 100644\n--- a/refs.c\n+++ b/refs.c\n@@ -141,7 +141,8 @@ static struct ref_list *get_ref_dir(cons\n \t\t\tint flag;\n \t\t\tint namelen;\n \n-\t\t\tif (de->d_name[0] == '.')\n+\t\t\tif (de->d_name[0] == '.' && (de->d_name[1] == '\\0'\n+\t\t\t || (de->d_name[1] == '.' && de->d_name[2] == '\\0')))\n \t\t\t\tcontinue;\n \t\t\tnamelen = strlen(de->d_name);\n"},{"id":"296717","messageId":"7v8xi9fjw9.fsf@assigned-by-dhcp.cox.net","threadId":"43096","inReplyTo":"20061118041137.6064.75827.stgit@machine.or.cz","subject":"Re: [PATCH] Do not ignore hidden refs","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-18T04:39:34Z","receivedAt":"2006-11-18T04:39:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> Some of the ref manipulation tools (git-for-each-ref and git-show-ref in\n> particular) would not handle hidden (~ /^\\./) refs.\n\nrefs.c::check_ref_format() seems to suggest that any ref whose\npath component begins with a dot is invalid (since October last\nyear), so I am a bit surprised you are bringing this up now. Do\nyou know of specific examples where this is not enforced? It\ncould even be argued that the places in the system that allow\nsuch a ref are buggy.\n\nI do not recall why we decided that this particular restriction\nwas needed (I do understand the other three restrictions --- see\ncommit log of 03feddd6), although I do think this is not a\ngratuitous change but comes from a list discussion. I suspect\nit was to avoid confusion with \"..\" operator (\"...\" was added\nmuch later in July this year), but it is not consistent that we\ndo not forbid the ones that end with a dot.\n\nMaybe we should have found this inconsistency and added \"names\nthat end with a dot\" to the forbidden category when we\nintroduced the symmetric difference, but apparently nobody\nnoticed. Right now foo...bar is seriously ambiguous. Even\nthough it cannot be \"foo\" .. \".bar\" (because \".bar\" is not a\nvalid refname), it can be \"foo.\" .. \"bar\" or \"foo\" ... \"bar\",\nand worse yet spelling longhand form \"refs/heads/foo.\" does not\nhelp to disambiguate this.\n\n"},{"id":"298220","messageId":"20061118045323.GK7201@pasky.or.cz","threadId":"43096","inReplyTo":"7v8xi9fjw9.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Do not ignore hidden refs","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-18T04:53:23Z","receivedAt":"2006-11-18T04:53:23Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Sat, Nov 18, 2006 at 05:39:34AM CET, Junio C Hamano wrote:\n> Petr Baudis writes:\n> \n> > Some of the ref manipulation tools (git-for-each-ref and git-show-ref in\n> > particular) would not handle hidden (~ /^\\./) refs.\n> \n> refs.c::check_ref_format() seems to suggest that any ref whose\n> path component begins with a dot is invalid (since October last\n> year), so I am a bit surprised you are bringing this up now.\n\nOops, I must've forgotten that already.\n\n> Do you know of specific examples where this is not enforced? It\n> could even be argued that the places in the system that allow\n> such a ref are buggy.\n\nCogito creates such refs for internal purposes in two scenarios, on the\nother hand it could be argued that in one of those cases the file has no\nbusiness in refs/ at all (temporary fetching refs, but they may be\nactually symrefs) and in the other case it has no business in refs/heads/\nat all (pointers to shelved changes in a branch).\n\nHowever, I in fact *did* intend to make leading-dot refnames a public\ninterface. The thing is, I need a way to mark some tags as private to\nyour repository if Cogito is to support autopushing tags, and I still\nthink the most elegant way to do that is to make them like hidden files.\nAlternative suggestions welcome.\n\nI don't *need* but it might be nice to have also private heads, for\npossible setups when you declare heads namespace of two repositories\nmatching 1:1 but would like to temporarily make a short-lived head in\none of them or so.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nThe meaning of Stonehenge in Traflamadorian, when viewed from above, is:\n\"Replacement part being rushed with all possible speed.\"\n"},{"id":"298027","messageId":"7vzmapdxki.fsf@assigned-by-dhcp.cox.net","threadId":"43096","inReplyTo":"20061118045323.GK7201@pasky.or.cz","subject":"Re: [PATCH] Do not ignore hidden refs","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-18T07:27:09Z","receivedAt":"2006-11-18T07:27:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> I don't *need* but it might be nice to have also private heads, for\n> possible setups when you declare heads namespace of two repositories\n> matching 1:1 but would like to temporarily make a short-lived head in\n> one of them or so.\n\nI agree that different classes of heads and tags (not just\n\"public\" vs \"private\") may come in handy in different workflows.\n\nI think, however, if we (collectively as all the Porcelain\nwriters although I am not really one of them) are to support it,\nthey should not make distinction to the core, and it should be\nhandled with the agreed-upon convention. In other words, if\n\".bar\" were a valid refname to the core then I would agree that\nnot packing them had definitely been a bug.\n\nAnd we already have one such convention of using refs/remotes\nfor tracking branches, which is promoted to become the default\n(thus an official BCP).\n\nPersonally I established a convention to treat heads/??/* as\n\"private namespace\" while using heads/* as public refs for my\nown work (I do that for git.git as people know, and I do that\nfor my day job project as well). I do not think it is a great\nenough convention to be promoted as the official BCP, but it has\nbeen good enough for me, especially commands like \"show-branch\"\nand \"tag -l\" understands the shell-style filegrobs (e.g\n\"show-branch master heads/??/*\" would show what's yet to be\npolished and merged).\n\n\n"},{"id":"294692","messageId":"20061118074119.GA2338@spearce.org","threadId":"43096","inReplyTo":"7vzmapdxki.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Do not ignore hidden refs","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-18T07:41:19Z","receivedAt":"2006-11-18T07:41:19Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Personally I established a convention to treat heads/??/* as\n> \"private namespace\" while using heads/* as public refs for my\n> own work (I do that for git.git as people know, and I do that\n> for my day job project as well). I do not think it is a great\n> enough convention to be promoted as the official BCP, but it has\n> been good enough for me, especially commands like \"show-branch\"\n> and \"tag -l\" understands the shell-style filegrobs (e.g\n> \"show-branch master heads/??/*\" would show what's yet to be\n> polished and merged).\n\nWe use refs/heads/??/* as \"developer specific\" namespaces.\n\nThat is we use an update hook in our central repository to control\nwho can push into refs/heads/??/*. If ?? matches the unix account\nholder's initials then they can push into that name, otherwise\nthey can't. This prevents any sort of naming collisions between\ndevelopers.\n\nTo make things slightly easier I've also suggested that people name\ntheir local branches with the same ??/ prefix as they need to use\non the central repository, thereby making the branch name the same\neverywhere. This is actually one reason why git-completion.bash\nsuggests \"??/foo:??/foo\" when completing a branch name to git-push.\n:)\n\nSo I don't think its a great idea to assume by default that\nrefs/heads/??/* is private to this repository.\n\n\nThough on second thought maybe we should be using developer private\nrepositories with object alternates pointing at a central repository.\nBut that means users have to manipulate URLs to fetch another\ndeveloper's branch vs. just using an existing remote..url,\nwhich is the main reason we put everything into one repository.\n\n-- \n"},{"id":"298529","messageId":"Pine.LNX.4.64.0611180933360.3692@woody.osdl.org","threadId":"43096","inReplyTo":"20061118041137.6064.75827.stgit@machine.or.cz","subject":"Re: [PATCH] Do not ignore hidden refs","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-18T17:35:18Z","receivedAt":"2006-11-18T17:35:18Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 18 Nov 2006, Petr Baudis wrote:\n>\n> Some of the ref manipulation tools (git-for-each-ref and git-show-ref in\n> particular) would not handle hidden (~ /^\\./) refs. This may be an\n> acceptable or possibly even desirable behaviour for the ref walkers and\n> repackers, but git-show-ref hiddenrefname must work.\n\nNo.\n\nRefnames MUST NOT start with a \".\". \n\nIt's not even about the traditional unix \"hidden file\" thing. It's simply \na syntactic issue. A ref cannot start with a \".\", because we use things \nlike \"..\" and \"...\" to separate them.\n\nFor the same reason, a ref must not contain - anywhere in its name - a \"^\" \nor a \"..\" or the other magic characters.\n\nIf you want to hide refs, you should do so some other way.\n\n"},{"id":"293989","messageId":"7vr6w0eh6k.fsf@assigned-by-dhcp.cox.net","threadId":"43096","inReplyTo":"Pine.LNX.4.64.0611180933360.3692@woody.osdl.org","subject":"Re: [PATCH] Do not ignore hidden refs","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-18T18:35:47Z","receivedAt":"2006-11-18T18:35:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Sat, 18 Nov 2006, Petr Baudis wrote:\n>>\n>> Some of the ref manipulation tools (git-for-each-ref and git-show-ref in\n>> particular) would not handle hidden (~ /^\\./) refs. This may be an\n>> acceptable or possibly even desirable behaviour for the ref walkers and\n>> repackers, but git-show-ref hiddenrefname must work.\n>\n> No.\n>\n> Refnames MUST NOT start with a \".\". \n>\n> It's not even about the traditional unix \"hidden file\" thing. It's simply \n> a syntactic issue. A ref cannot start with a \".\", because we use things \n> like \"..\" and \"...\" to separate them.\n\nWe do not forbid a refname that ends with a \".\", but I think it\nwas a mistake. We _can_ disambiguate the ones that begin with a\n\".\" by saying \"whatever..heads/.I-begin-with-dot\", but not the\nones that end with \"heads/I-end-with-dot...end-of-range\".\n"},{"id":"297485","messageId":"20061118192830.GP7201@pasky.or.cz","threadId":"43096","inReplyTo":"7vzmapdxki.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Do not ignore hidden refs","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-18T19:28:30Z","receivedAt":"2006-11-18T19:28:30Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Sat, Nov 18, 2006 at 08:27:09AM CET, Junio C Hamano wrote:\n> I think, however, if we (collectively as all the Porcelain\n> writers although I am not really one of them) are to support it,\n> they should not make distinction to the core, and it should be\n> handled with the agreed-upon convention.\n\nI guess I agree.\n\n> Personally I established a convention to treat heads/??/* as\n> \"private namespace\" while using heads/* as public refs for my\n> own work (I do that for git.git as people know, and I do that\n> for my day job project as well). I do not think it is a great\n> enough convention to be promoted as the official BCP, but it has\n> been good enough for me, especially commands like \"show-branch\"\n> and \"tag -l\" understands the shell-style filegrobs (e.g\n> \"show-branch master heads/??/*\" would show what's yet to be\n> polished and merged).\n\nThat's way too arbitrary for my taste, I think I needn't explain why.\n:-)\n\n\nWhat about leading underscore?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nThe meaning of Stonehenge in Traflamadorian, when viewed from above, is:\n\"Replacement part being rushed with all possible speed.\"\n"},{"id":"294859","messageId":"7vejs0cz5s.fsf@assigned-by-dhcp.cox.net","threadId":"43096","inReplyTo":"20061118192830.GP7201@pasky.or.cz","subject":"Re: [PATCH] Do not ignore hidden refs","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-18T19:50:23Z","receivedAt":"2006-11-18T19:50:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> On Sat, Nov 18, 2006 at 08:27:09AM CET, Junio C Hamano wrote:\n>> I think, however, if we (collectively as all the Porcelain\n>> writers although I am not really one of them) are to support it,\n>> they should not make distinction to the core, and it should be\n>> handled with the agreed-upon convention.\n>\n> I guess I agree.\n>\n>> ... I do not think it is a great\n>> enough convention to be promoted as the official BCP, but it has\n>> been good enough for me, ...\n>\n> That's way too arbitrary for my taste, I think I needn't explain why.\n\nBecause _I_ explained why already ;-).\n\n> What about leading underscore?\n\nI would rather prefer to do refs/{heads,private}/ and allow\ncheckout to treat either of them as branches. We are talking\nabout allowing checkout to go to a non-branch by storing a raw\ncommit object name in HEAD instead of leaving it as a symref, so\nwe know we are going to touch that area already.\n\n\n\n"},{"id":"297665","messageId":"20061118195520.GQ7201@pasky.or.cz","threadId":"43096","inReplyTo":"7vejs0cz5s.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Do not ignore hidden refs","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-18T19:55:20Z","receivedAt":"2006-11-18T19:55:20Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Sat, Nov 18, 2006 at 08:50:23PM CET, Junio C Hamano wrote:\n> Petr Baudis writes:\n> \n> > On Sat, Nov 18, 2006 at 08:27:09AM CET, Junio C Hamano wrote:\n> >> ... I do not think it is a great\n> >> enough convention to be promoted as the official BCP, but it has\n> >> been good enough for me, ...\n> >\n> > That's way too arbitrary for my taste, I think I needn't explain why.\n> \n> Because _I_ explained why already ;-).\n\nOops. ;-) Me too sloppy today, sorry.\n\n> > What about leading underscore?\n> \n> I would rather prefer to do refs/{heads,private}/ and allow\n> checkout to treat either of them as branches. We are talking\n> about allowing checkout to go to a non-branch by storing a raw\n> commit object name in HEAD instead of leaving it as a symref, so\n> we know we are going to touch that area already.\n\nCogito _heavily_ assumes on a lot of places that heads live in\nrefs/heads/ and tags live in refs/tags/. Besides, I think private tags\nare much more useful to support than private heads (not that you would\nnecessarily make more private tags than private heads, but you are more\nlikely to want tags autopushed than heads; or perhaps that just in my\nhead?). So what about refs/{heads,tags}/private/? :-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nThe meaning of Stonehenge in Traflamadorian, when viewed from above, is:\n\"Replacement part being rushed with all possible speed.\"\n"},{"id":"295744","messageId":"7vy7q8bjwn.fsf@assigned-by-dhcp.cox.net","threadId":"43096","inReplyTo":"7vejs0cz5s.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Do not ignore hidden refs","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-18T20:05:12Z","receivedAt":"2006-11-18T20:05:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n>> What about leading underscore?\n>\n> I would rather prefer to do refs/{heads,private}/ and allow\n> checkout to treat either of them as branches. We are talking\n> about allowing checkout to go to a non-branch by storing a raw\n> commit object name in HEAD instead of leaving it as a symref, so\n> we know we are going to touch that area already.\n\nOops. Consider this rescinded. I myself already talked about\n\"not necessarily just public vs private\". Silly me.\n\nI think this is related to the common gripe of \"why can't Junio\nmark pu to be rewinded in his public repository\". We should be\nable to leave the branch grouping to users.\n\nNot just public vs private, but I can see an organization that\nuses something like this:\n\n heads/1.5/{maint,master,next,pu} are to maintain and advance 1.5 series\n heads/1.5/topics/{foo,bar} are topics applicable to 1.5\n heads/2.0/{maint,master,next,pu} are to maintain and advance 2.0 series\n heads/2.0/topics/{foo,bar} are topics applicable only to 2.0\n heads/topics/{frotz,nitfol} are topics applicable to both\n\nand wanting to view all the topics, only things related to 1.5,\netc. So Porcelains _can_ enforce their own policies to arrange\nthings differently but we should also be able to let the users\n(and project branch naming policy) to do what we've been talking\nabout by saying:\n\n\tuse heads/private/ for your own stuff. And have\n\tconfiguration that says \"heads/private/\" are private\n\tbranches that are not subject to default\n\tpushing/pulling.\n\nThe real instruction from the project would say what the syntax\nfor telling that to git but I think you got the idea...\n"},{"id":"295677","messageId":"20061118231842.GS7201@pasky.or.cz","threadId":"43096","inReplyTo":"7vy7q8bjwn.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Do not ignore hidden refs","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-18T23:18:42Z","receivedAt":"2006-11-18T23:18:42Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Sat, Nov 18, 2006 at 09:05:12PM CET, Junio C Hamano wrote:\n> \tuse heads/private/ for your own stuff. And have\n> \tconfiguration that says \"heads/private/\" are private\n> \tbranches that are not subject to default\n> \tpushing/pulling.\n> \n> The real instruction from the project would say what the syntax\n> for telling that to git but I think you got the idea...\n\nYes, I fully agree that being able to have this configurable is cool,\nbut I'm still interested in providing a sensible out-of-the-box default\nconfiguration for Cogito to use. But if we can agree that heads/private/\nand tags/private/ are good BCP candidates, that's great. (The only\npossible problem is a lot of typing incurred. Perhaps the default refs\nsearch order should become configurable first.)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nThe meaning of Stonehenge in Traflamadorian, when viewed from above, is:\n\"Replacement part being rushed with all possible speed.\"\n"},{"id":"296247","messageId":"7vmz6o9t3s.fsf@assigned-by-dhcp.cox.net","threadId":"43096","inReplyTo":"20061118231842.GS7201@pasky.or.cz","subject":"Re: [PATCH] Do not ignore hidden refs","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-19T00:29:27Z","receivedAt":"2006-11-19T00:29:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> On Sat, Nov 18, 2006 at 09:05:12PM CET, Junio C Hamano wrote:\n>> \tuse heads/private/ for your own stuff. And have\n>> \tconfiguration that says \"heads/private/\" are private\n>> \tbranches that are not subject to default\n>> \tpushing/pulling.\n>> \n>> The real instruction from the project would say what the syntax\n>> for telling that to git but I think you got the idea...\n>\n> Yes, I fully agree that being able to have this configurable is cool,\n> but I'm still interested in providing a sensible out-of-the-box default\n> configuration for Cogito to use. But if we can agree that heads/private/\n> and tags/private/ are good BCP candidates, that's great. (The only\n> possible problem is a lot of typing incurred. Perhaps the default refs\n> search order should become configurable first.)\n\nIt is not clear from the discussion so far why it is necessary\n(or even is a good change), and I suspect a confusion to mix up\ntwo different things has slipped in somewhere in the discussion.\n\nMy understanding of your original plan was to use \".foo\" as\na private thing for Cogito to use to implement some cleverness\nwhen the user talks about the branch \"foo\" (just like StGIT\nuses \"refs/bases/foo\" to keep track of its private stuff related\nto user branch \"foo\"). When the user says \"my 'foo' branch\",\nyou were going to munge that name into \".foo\" and use both to\nimplement that cleverness (just like StGIT uses \"refs/bases/foo\"\nin addition to \"refs/heads/foo\" when the user is talking about\nhis branch \"foo\").\n\nI would rather think that it would actively be a bad thing to\nmake the core level to consider heads/private/foo and heads/foo\nambiguous. When the user says \"my 'foo' branch\" that should\nmean the \"foo\" branch not the \"private/foo\" branch.\n\nWhich certainly suggests that heads/private/, as a user visible\nconvention to keep developer-repository private stuff for local\nuse, is too verbose.\n\nStGIT's use of refs/bases (i.e. outside refs/heads) is probably\nsensible because it is not something the end user should\ndirectly muck with nor check out. If Porcelains want some\n\"special branch\" for their own use to do their magic, however,\nthe ref cannot be outside refs/heads for it to be pointed at by\nHEAD to become the \"current branch\" (\"bisect\" command comes to\nmind, and I suspect \"cg-seek\" would have similar issues). But\nthat kind of use is all under controll of the Porcelain, and I\nwould imagine \"too long to type\" objection would not apply.\n"},{"id":"293839","messageId":"20061119004817.GT7201@pasky.or.cz","threadId":"43096","inReplyTo":"7vmz6o9t3s.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Do not ignore hidden refs","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-19T00:48:17Z","receivedAt":"2006-11-19T00:48:17Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Sun, Nov 19, 2006 at 01:29:27AM CET, Junio C Hamano wrote:\n> My understanding of your original plan was to use \".foo\" as\n> a private thing for Cogito to use to implement some cleverness\n> when the user talks about the branch \"foo\" (just like StGIT\n> uses \"refs/bases/foo\" to keep track of its private stuff related\n> to user branch \"foo\"). When the user says \"my 'foo' branch\",\n> you were going to munge that name into \".foo\" and use both to\n> implement that cleverness (just like StGIT uses \"refs/bases/foo\"\n> in addition to \"refs/heads/foo\" when the user is talking about\n> his branch \"foo\").\n\n(Not a plan, that's what I do now. ;-)\n\nYes, that's correct, but it's not what I'm talking about anymore - sorry\nfor the confusion. The proper solution for this is of course to move\nthis around in the refs/ hierarchy out of heads to a more suitable\nplace. I'm going to do that in few moments.\n\nWhat I'm talking about now are _real_ user-visible and user-created\nrefs, which should however stay local to the repository the user created\nthem in.\n\n> I would rather think that it would actively be a bad thing to\n> make the core level to consider heads/private/foo and heads/foo\n> ambiguous. When the user says \"my 'foo' branch\" that should\n> mean the \"foo\" branch not the \"private/foo\" branch.\n> \n> Which certainly suggests that heads/private/, as a user visible\n> convention to keep developer-repository private stuff for local\n> use, is too verbose.\n\nI don't think the automatic lookup of the branch with private/ prepended\nis too bad a thing, but if you have a better solution...\n\n> StGIT's use of refs/bases (i.e. outside refs/heads) is probably\n> sensible because it is not something the end user should\n> directly muck with nor check out. If Porcelains want some\n> \"special branch\" for their own use to do their magic, however,\n> the ref cannot be outside refs/heads for it to be pointed at by\n> HEAD to become the \"current branch\" (\"bisect\" command comes to\n> mind, and I suspect \"cg-seek\" would have similar issues). But\n> that kind of use is all under controll of the Porcelain, and I\n> would imagine \"too long to type\" objection would not apply.\n\nYes, but what I have on mind are branches the _user_ wants to declare as\nlocal.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nThe meaning of Stonehenge in Traflamadorian, when viewed from above, is:\n\"Replacement part being rushed with all possible speed.\"\n"}]}