{"thread":{"id":"28200","subject":"Looking for a way to turn off/modify ref disambiguation","startedAt":"2011-08-23T19:26:48Z","lastAt":"2011-08-24T17:48:46Z","messageCount":7,"participants":["Nathan W. Panike","Jeff King","Junio C Hamano","Clemens Buchacher","Michael J Gruber","Jonathan Nieder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"174113","messageId":"CAPRoxBXjL3Y3KRd8R2guX9Ar374sw-pBhz1bCzNZxn1vC6XNPw@mail.gmail.com","threadId":"28200","inReplyTo":null,"subject":"Looking for a way to turn off/modify ref disambiguation","fromName":"Nathan W. Panike","fromEmail":"nathan.panike@gmail.com","sentAt":"2011-08-23T19:26:48Z","receivedAt":"2011-08-23T19:26:48Z","isPatch":false,"sender":{"key":"nathan.panike@gmail.com","avatar":"https://avatars.githubusercontent.com/u/389447?v=4"},"body":"A colleague at $dayjob recently caused corruption in our git\nrepository by accidentally running the command\n\ngit rebase origin stable\n\nwhere they meant to run\n\ngit rebase origin/stable\n\nThe git-rev-parse(1) man page says:\n\n...\n, e.g. master, heads/master, refs/heads/master\n\n A symbolic ref name. E.g. master typically means the commit object\nreferenced by refs/heads/master. If you happen to have both\nheads/master and tags/master, you can explicitly say heads/master to\ntell git which one you mean. When ambiguous, a is disambiguated\nby taking the first match in the following rules:\n\n 1. If $GIT_DIR/ exists, that is what you mean\n(this is usually useful only for HEAD, FETCH_HEAD, ORIG_HEAD,\nMERGE_HEAD and CHERRY_PICK_HEAD);\n 2. otherwise, refs/ if it exists;\n 3. otherwise, refs/tags/ if it exists;\n 4. otherwise, refs/heads/ if it exists;\n 5. otherwise, refs/remotes/ if it exists;\n 6. otherwise, refs/remotes//HEAD if it exists.\n...\n\nIs there any way to change this behavior, e.g., so that rule 6 becomes\nan error? Say, by setting a config option?\n\n==========\nNathan Panike\n"},{"id":"174122","messageId":"20110823211536.GA7759@sigill.intra.peff.net","threadId":"28200","inReplyTo":"CAPRoxBXjL3Y3KRd8R2guX9Ar374sw-pBhz1bCzNZxn1vC6XNPw@mail.gmail.com","subject":"Re: Looking for a way to turn off/modify ref disambiguation","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-08-23T21:15:36Z","receivedAt":"2011-08-23T21:15:36Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 23, 2011 at 02:26:48PM -0500, Nathan W. Panike wrote:\n\n> 1. If $GIT_DIR/ exists, that is what you mean\n> (this is usually useful only for HEAD, FETCH_HEAD, ORIG_HEAD,\n> MERGE_HEAD and CHERRY_PICK_HEAD);\n> 2. otherwise, refs/ if it exists;\n> 3. otherwise, refs/tags/ if it exists;\n> 4. otherwise, refs/heads/ if it exists;\n> 5. otherwise, refs/remotes/ if it exists;\n> 6. otherwise, refs/remotes//HEAD if it exists.\n> ...\n> \n> Is there any way to change this behavior, e.g., so that rule 6 becomes\n> an error? Say, by setting a config option?\n\nYou can remove the remote HEAD reference with:\n\n git remote set-head origin -d\n\nThat will only fix that particular repo, though. There is no config\noption to disable it for all newly cloned repos.\n\n-Peff\n"},{"id":"174127","messageId":"7vei0brdiq.fsf@alter.siamese.dyndns.org","threadId":"28200","inReplyTo":"CAPRoxBXjL3Y3KRd8R2guX9Ar374sw-pBhz1bCzNZxn1vC6XNPw@mail.gmail.com","subject":"Re: Looking for a way to turn off/modify ref disambiguation","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-08-23T22:03:57Z","receivedAt":"2011-08-23T22:03:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Nathan W. Panike\" writes:\n\n> 1. If $GIT_DIR/ exists, that is what you mean\n> (this is usually useful only for HEAD, FETCH_HEAD, ORIG_HEAD,\n> MERGE_HEAD and CHERRY_PICK_HEAD);\n> 2. otherwise, refs/ if it exists;\n> 3. otherwise, refs/tags/ if it exists;\n> 4. otherwise, refs/heads/ if it exists;\n> 5. otherwise, refs/remotes/ if it exists;\n> 6. otherwise, refs/remotes//HEAD if it exists.\n> ...\n>\n> Is there any way to change this behavior, e.g., so that rule 6 becomes\n> an error?\n\nYou will force people to say \"git log origin/master..master\" to measure\ntheir progress if you did so, when \"git log origin..master\" has been the\nway described in many git books and documentation pages floating on the\nweb.\n\nI think it is _very_ unlikely that such a change is going to happen.\n"},{"id":"174140","messageId":"20110824065412.GA10800@ecki","threadId":"28200","inReplyTo":"CAPRoxBXjL3Y3KRd8R2guX9Ar374sw-pBhz1bCzNZxn1vC6XNPw@mail.gmail.com","subject":"Re: Looking for a way to turn off/modify ref disambiguation","fromName":"Clemens Buchacher","fromEmail":"drizzd@aon.at","sentAt":"2011-08-24T06:54:12Z","receivedAt":"2011-08-24T06:54:12Z","isPatch":false,"sender":{"key":"drizzd@gmx.net","avatar":"https://avatars.githubusercontent.com/u/59082?v=4"},"body":"Hi Nathan,\n\nOn Tue, Aug 23, 2011 at 02:26:48PM -0500, Nathan W. Panike wrote:\n> \n> Is there any way to change this behavior, e.g., so that rule 6 becomes\n> an error? Say, by setting a config option?\n\nI know you're trying to improve git. I do not want to discourage\nthat. But with little UI annoyances like this, it's usually not\nworth it. Git has countless magic tricks like this. It's a bit\nlike perl in that regard. Assuming that we agree on what we would\nlike to get rid of (which is the hard part), it would still break\nbackwards compatibility. Maintaining a switch, on the other hand,\nis overhead and in the end it would make git even more complicated,\nbecause now the behavior of core commands depends on user\nconfiguration.\n\nBut once you accept the fact that this is what git is, you can\ntackle the problem in a different way:\n\n> A colleague at $dayjob recently caused corruption in our git\n> repository by accidentally running the command\n> \n> git rebase origin stable\n\nOk, mistakes happen. But that's exactly why you have git: To be\nable to deal with mistakes gracefully. So use git to review and\ntest changes before they get declared as a stable release (stable\nenough to be used internally, at least). Then mistakes usually\nbecome a local problem and can be undone using the reflog.\n\nClemens\n"},{"id":"174142","messageId":"4E54C373.1070702@drmicha.warpmail.net","threadId":"28200","inReplyTo":"7vei0brdiq.fsf@alter.siamese.dyndns.org","subject":"Re: Looking for a way to turn off/modify ref disambiguation","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-08-24T09:25:07Z","receivedAt":"2011-08-24T09:25:07Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 24.08.2011 00:03:\n> \"Nathan W. Panike\" writes:\n> \n>> 1. If $GIT_DIR/ exists, that is what you mean\n>> (this is usually useful only for HEAD, FETCH_HEAD, ORIG_HEAD,\n>> MERGE_HEAD and CHERRY_PICK_HEAD);\n>> 2. otherwise, refs/ if it exists;\n>> 3. otherwise, refs/tags/ if it exists;\n>> 4. otherwise, refs/heads/ if it exists;\n>> 5. otherwise, refs/remotes/ if it exists;\n>> 6. otherwise, refs/remotes//HEAD if it exists.\n>> ...\n>>\n>> Is there any way to change this behavior, e.g., so that rule 6 becomes\n>> an error?\n> \n> You will force people to say \"git log origin/master..master\" to measure\n> their progress if you did so, when \"git log origin..master\" has been the\n> way described in many git books and documentation pages floating on the\n> web.\n\nI haven't come across advice like that. In our own documentation, we\ndon't explain it, and in our user-manual \"origin\" is used as the name of\na branch.\n\nI consider that advice very bad indeed:\n\nIf \"origin..master\" is resolved to \"master ^origin/master\", then\nobviously \"origin..next\" is resolved to \"next ^origin/next\" - but it is\nnot, of course, and the fact that \"origin\" is resolved to\n\"origin/master\" depends on the content of \"origin/HEAD\", which the\nupstream repo owner controls (in the sense that upstream's HEAD\ndetermines it), not downstream.\n\nThus, teaching \"origin..master\" as a way of measuring your progress is\ngrossly misleading. \"@{u}..\" does that when you're on the branch in\nquestion, and we have no notation for \"@{u(master)}..master\".\n\nSide note:\n\nIn fact, who groks symbolic refs anyway? I mean, git-reset sets HEAD and\ngit-checkout does so, right? ;)\n(I'm afraid I need to clean up after myself in git-reset(1)...)\n\n> I think it is _very_ unlikely that such a change is going to happen.\n\nIf messing with the origin..master notation is the only fall-out I'm all\nfor it.\n\nBut note that the OP only asked for a way to turn off disambiguation,\nnot for a change of defaults..\n\nMichael\n"},{"id":"174166","messageId":"20110824163747.GA9184@elie.gateway.2wire.net","threadId":"28200","inReplyTo":"4E54C373.1070702@drmicha.warpmail.net","subject":"Re: Looking for a way to turn off/modify ref disambiguation","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-08-24T16:37:47Z","receivedAt":"2011-08-24T16:37:47Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Michael J Gruber wrote:\n\n> \"@{u}..\" does that when you're on the branch in\n> question, and we have no notation for \"@{u(master)}..master\".\n\n\"master@{u}..master\" works, though it's not very short.\n"},{"id":"174169","messageId":"7vr54apuo1.fsf@alter.siamese.dyndns.org","threadId":"28200","inReplyTo":"4E54C373.1070702@drmicha.warpmail.net","subject":"Re: Looking for a way to turn off/modify ref disambiguation","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-08-24T17:48:46Z","receivedAt":"2011-08-24T17:48:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> I haven't come across advice like that....\n> I consider that advice very bad indeed:\n>\n> If \"origin..master\" is resolved to...\n\nPerhaps origin..master was a bad example for you [*1*]; but the point is\nyou can say \"origin\" to mean the commit at the tip of the remote tracking\nbranch that the repository you cloned from deemed as its primary branch\nanywhere we expect a commit on the command line.\n\nSo if you do not like \"log origin..master\", then say \"git log origin\"\ninstead and the point still stands.\n\n[Footnote]\n\n*1* \"origin..master\" is still a perfectly good example in tutorials to\nteach people who use the workflow with a single at the central repository,\ni.e. the simplest for esapee from CVS/SVN. You may have \"frotz\" topic and\n\"nitfol\" topic branches locally cooking your own changes, and you can\nmeasure their progress against the central repository with \"origin..frotz\"\nand \"origin..nitfol\".\n"}]}