{"thread":{"id":"26292","subject":"Creating remote branch called HEAD corrupts remote clones","startedAt":"2011-01-17T10:02:49Z","lastAt":"2011-05-09T22:09:52Z","messageCount":40,"participants":["Stephen Kelly","Thomas Rast","Erik Faye-Lund","Felipe Contreras","Wesley J. Landaker","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"159553","messageId":"ih1449$ul6$1@dough.gmane.org","threadId":"26292","inReplyTo":null,"subject":"Creating remote branch called HEAD corrupts remote clones","fromName":"Stephen Kelly","fromEmail":"steveire@gmail.com","sentAt":"2011-01-17T10:02:49Z","receivedAt":"2011-01-17T10:02:49Z","isPatch":false,"sender":{"key":"steveire@gmail.com","avatar":null},"body":"\nHi,\n\nOn Friday we had an issue where a developer pushed a branch called HEAD to \nthe remote server. The result was that other developers could not pull or \npush. I have not been able to reproduce the exact issue locally, but this \nscript shows that the bob clone behaves oddly on each pull. That is a \nsymptom we saw on Friday. However, bob is still able to push, which we were \nnot able to. That point could be something to do with how the kde git \ninfrastructure is configured.\n\nmkdir remote\ncd remote/\ngit init --bare\ncd ../\ngit clone remote/ alice\ncd alice/\necho test >> file\ngit add file\ngit commit -am w\ngit push origin master\necho test >> file\ngit commit -am w\ngit branch HEAD\ngit push origin HEAD\ngit push\ncd ..\ngit clone remote bob\ncd bob/\ngit pull --rebase\necho test >> file\ngit commit -am w\ngit push\ngit pull\ngit pull\ngit pull\n\nThere were also messages like this:\n\n$ git pull\nremote: Counting objects: 5, done.\nremote: Total 3 (delta 0), reused 0 (delta 0)\nUnpacking objects: 100% (3/3), done.\nFrom /home/kde-devel/dev/src/playground/git/tmp/remote\n + 1434cd2...dd30974 HEAD -> origin/HEAD (forced update)\nerror: Ref refs/remotes/origin/master is at \ndd3097498a6c1c5bc73ad1f2ff3b7969a6f6d059 but expected \n1434cd2bb9823d2d2b1548c75fdd4ff8b1feddc1\n ! 1434cd2..2fb560d master -> origin/master (unable to update local \nref)\n\nThe HEAD branch was created accidentally and the issue was resolved by doing \na git push origin -f :refs/heads/HEAD. Again though, git push -f is not \nsomething all developers are allowed to do on the kde git infrastructure, so \nuntil that was done, the repo was corrupt for everyone.\n\nShouldn't git forbit the creation of a branch called HEAD? Hopefully the \nprovided script can lead to the actual issue that caused the corruption of \nour repo.\n\nThanks,\n\nSteve.\n\n\n_______________________________________________\nKDE PIM mailing list kde-pim@kde.org\nhttps://mail.kde.org/mailman/listinfo/kde-pim\nKDE PIM home page at http://pim.kde.org/\n"},{"id":"159686","messageId":"ih95fg$62b$1@dough.gmane.org","threadId":"26292","inReplyTo":"ih1449$ul6$1@dough.gmane.org","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Stephen Kelly","fromEmail":"steveire@gmail.com","sentAt":"2011-01-20T11:14:56Z","receivedAt":"2011-01-20T11:14:56Z","isPatch":false,"sender":{"key":"steveire@gmail.com","avatar":null},"body":"Stephen Kelly wrote:\n\n> \n> Hi,\n> \n> On Friday we had an issue where a developer pushed a branch called HEAD to\n> the remote server. The result was that other developers could not pull or\n> push. \n\nDoes anyone have any thoughts/response on this?\n\nWhy does git not have a bug tracker?\n\nSteve.\n"},{"id":"159689","messageId":"201101201403.39174.trast@student.ethz.ch","threadId":"26292","inReplyTo":"ih95fg$62b$1@dough.gmane.org","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2011-01-20T13:03:38Z","receivedAt":"2011-01-20T13:03:38Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Stephen Kelly wrote:\n> Why does git not have a bug tracker?\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/136500\n\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"159692","messageId":"AANLkTinNNBupCi09_W60qdDGFc5CN-p=rKaf_FKW0kj1@mail.gmail.com","threadId":"26292","inReplyTo":"201101201403.39174.trast@student.ethz.ch","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Stephen Kelly","fromEmail":"steveire@gmail.com","sentAt":"2011-01-20T15:05:36Z","receivedAt":"2011-01-20T15:05:36Z","isPatch":false,"sender":{"key":"steveire@gmail.com","avatar":null},"body":"Ok so there was some movement with the result that no one uses what was set up.\n\nPresumably because git developers don't want a bug tracker.\n\nSo how can I ensure that this particular issue doesn't get lost? Is\nthere no way except hope that people get involved in fixing it\nstraight away, and fix it straight away before they forget about it?\n\nWe worked around this on the KDE side by forbidding pushing any ref\nwith the name HEAD to the remote, but it's still a git bug.\n\nOn 1/20/11, Thomas Rast wrote:\n> Stephen Kelly wrote:\n>> Why does git not have a bug tracker?\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/136500\n>\n>\n> --\n> Thomas Rast\n> trast@{inf,student}.ethz.ch\n>\n"},{"id":"159694","messageId":"AANLkTinoET4vBxVdfSejFmzwRaA=0AVdie5gmMvx44T5@mail.gmail.com","threadId":"26292","inReplyTo":"AANLkTinNNBupCi09_W60qdDGFc5CN-p=rKaf_FKW0kj1@mail.gmail.com","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2011-01-20T15:41:54Z","receivedAt":"2011-01-20T15:41:54Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Thu, Jan 20, 2011 at 4:05 PM, Stephen Kelly wrote:\n> Ok so there was some movement with the result that no one uses what was set up.\n>\n> Presumably because git developers don't want a bug tracker.\n>\n> So how can I ensure that this particular issue doesn't get lost? Is\n> there no way except hope that people get involved in fixing it\n> straight away, and fix it straight away before they forget about it?\n>\n\nYou could always fix it yourself, and submit a patch.\n"},{"id":"159695","messageId":"AANLkTimVrBEdmz9e0qd4BR=VnQ0qNS7QZSvGA-B=5Uev@mail.gmail.com","threadId":"26292","inReplyTo":"AANLkTinoET4vBxVdfSejFmzwRaA=0AVdie5gmMvx44T5@mail.gmail.com","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Stephen Kelly","fromEmail":"steveire@gmail.com","sentAt":"2011-01-20T16:00:46Z","receivedAt":"2011-01-20T16:00:46Z","isPatch":false,"sender":{"key":"steveire@gmail.com","avatar":null},"body":"On Thu, Jan 20, 2011 at 4:41 PM, Erik Faye-Lund wrote:\n> On Thu, Jan 20, 2011 at 4:05 PM, Stephen Kelly wrote:\n>> Ok so there was some movement with the result that no one uses what was set up.\n>>\n>> Presumably because git developers don't want a bug tracker.\n>>\n>> So how can I ensure that this particular issue doesn't get lost? Is\n>> there no way except hope that people get involved in fixing it\n>> straight away, and fix it straight away before they forget about it?\n>>\n>\n> You could always fix it yourself, and submit a patch.\n>\n\nCorrect. That would be a big rampup though and I might give up, move\non or forget and then no one would do it because everyone has\nforgotten about it. I mean that in the general sense of any bug that\ngets posted to this mailing list.\n\nBut I'm not trying to change how git people work. I'm just trying to\ndiscover what the states of a bug in git should be understood to be\nafter it is emailed to this list and before it's in master. So far it\nseems there is only one intermediate state: \"Limbo, maybe forgotten.\nYou should email the list again\"\n\nThanks,\n\nSteve.\n"},{"id":"159697","messageId":"AANLkTikvVaSTV8hVjDXLvOEEDv5qr19ybk3Cm--+bgWA@mail.gmail.com","threadId":"26292","inReplyTo":"ih95fg$62b$1@dough.gmane.org","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2011-01-20T17:32:40Z","receivedAt":"2011-01-20T17:32:40Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\nOn Thu, Jan 20, 2011 at 1:14 PM, Stephen Kelly wrote:\n> Stephen Kelly wrote:\n>> On Friday we had an issue where a developer pushed a branch called HEAD to\n>> the remote server. The result was that other developers could not pull or\n>> push.\n>\n> Does anyone have any thoughts/response on this?\n\nCan you list a series of steps to reproduce this?\n\n> Why does git not have a bug tracker?\n\nBecause it's not needed. If you have an issue, post the issue as you\nwould file a bug:\n Which version of git?\n Which kind of network transport was used?\n Is this reproducible?\n\nChances are, if this is reproducible in the latest version, someone\nwould fix it soon enough. If not, and it's important to you, you would\nping back. If other people find this issue, they would send another\nemail.\n\nIn fact, if you really want to help, you could clone the latest\n'master' to see if this still happening, narrow down the steps needed\nto reproduce this, write a test to trigger it and send a patch.\nCertainly, a test case that constantly fails would be a constant\nremainder that there is a bug.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"159700","messageId":"201101201221.00977.wjl@icecavern.net","threadId":"26292","inReplyTo":"AANLkTikvVaSTV8hVjDXLvOEEDv5qr19ybk3Cm--+bgWA@mail.gmail.com","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Wesley J. Landaker","fromEmail":"wjl@icecavern.net","sentAt":"2011-01-20T19:21:00Z","receivedAt":"2011-01-20T19:21:00Z","isPatch":false,"sender":{"key":"wjl@icecavern.net","avatar":"https://avatars.githubusercontent.com/u/67229?v=4"},"body":"On Thursday, January 20, 2011 10:32:40 Felipe Contreras wrote:\n> Hi,\n> \n> On Thu, Jan 20, 2011 at 1:14 PM, Stephen Kelly wrote:\n> > Stephen Kelly wrote:\n> >> On Friday we had an issue where a developer pushed a branch called\n> >> HEAD to the remote server. The result was that other developers could\n> >> not pull or push.\n[...]\n> Which version of git?\n> Which kind of network transport was used?\n> Is this reproducible?\n\nFWIW, here is a quick demonstration of at least one problem with having a \nbranch called HEAD. You can make it and push it fine, but when cloning, you\ndon't get it.\n\n#!/bin/bash\ngit init --bare origin.git\ngit clone origin.git wc1\ncd wc1\ngit commit --allow-empty -m \"Initial rev\"\ngit checkout -b HEAD\ngit commit --allow-empty -m \"Make HEAD branch\"\ngit push --all\ncd ..\ngit clone origin.git wc2\ndiff -u <(cd wc1; git branch -a) <(cd wc2; git branch -a)\ndiff -u <(cd wc1; git log --all) <(cd wc2; git log --all)\n\nIf I do the following from wc2 I can get the branch manually:\n\ngit pull origin refs/heads/HEAD:HEAD\n\nI haven't played with it enough to see what other problems might arise.\n"},{"id":"159703","messageId":"7v62tjs66r.fsf@alter.siamese.dyndns.org","threadId":"26292","inReplyTo":"ih1449$ul6$1@dough.gmane.org","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-01-20T19:53:16Z","receivedAt":"2011-01-20T19:53:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stephen Kelly writes:\n\n> There were also messages like this:\n>\n> $ git pull\n> remote: Counting objects: 5, done.\n> remote: Total 3 (delta 0), reused 0 (delta 0)\n> Unpacking objects: 100% (3/3), done.\n> From /home/kde-devel/dev/src/playground/git/tmp/remote\n> + 1434cd2...dd30974 HEAD -> origin/HEAD (forced update)\n\nStephen, thanks, I think you have found a bug, not in this step but one\nstep before this 'git pull', where Bob pushes to the remote for the first\ntime after making a commit.\n\nThis issue is inherent in the way how the 'separate remotes' layout\nintroduced in 1.6.0 arranges the remote tracking mappings.\n\nThe refs/remotes/origin/HEAD in Bob's repository is supposed to be a\nsymbolic ref that points at the primary branch of the 'origin' remote\n(typically its master), e.g. \"ref: refs/remotes/origin/master\". But in\ngeneral, local 'refs/remotes/origin/X' for any value of X is to copy\n'refs/heads/X' from the 'origin'.\n\nOops. If the origin repository has 'refs/heads/HEAD', these rules\nobviously conflict with each other.\n\nIn this particular case, Bob pushes the change to his refs/heads/master to\nthe remote to update its refs/heads/master. The push at the same time\ntries to pretend that it fetched from the remote to update Bob's tracking\nbranches, so refs/remotes/origin/master in Bob's repository is also\nupdated to point at this commit.\n\nHowever, because Bob's refs/remotes/origin/HEAD is a symbolic ref that\npoints at his refs/remotes/origin/master, its value is also updated by\nthis push.\n\nBob's next fetch from remote will then notice that remotes/origin/HEAD he\nhas is different from refs/heads/HEAD the remote has, and tries to update\nit, which would obviously a non-fast-forward.\n\nI personally think it is reasonable to forbid HEAD or anything all caps\nthat ends with \"_HEAD\" as branch names. Opinions?\n"},{"id":"159711","messageId":"20110120203840.GA11468@sigill.intra.peff.net","threadId":"26292","inReplyTo":"7v62tjs66r.fsf@alter.siamese.dyndns.org","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-01-20T20:38:40Z","receivedAt":"2011-01-20T20:38:40Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jan 20, 2011 at 11:53:16AM -0800, Junio C Hamano wrote:\n\n> The refs/remotes/origin/HEAD in Bob's repository is supposed to be a\n> symbolic ref that points at the primary branch of the 'origin' remote\n> (typically its master), e.g. \"ref: refs/remotes/origin/master\". But in\n> general, local 'refs/remotes/origin/X' for any value of X is to copy\n> 'refs/heads/X' from the 'origin'.\n> \n> Oops. If the origin repository has 'refs/heads/HEAD', these rules\n> obviously conflict with each other.\n>\n> [...]\n>\n> I personally think it is reasonable to forbid HEAD or anything all caps\n> that ends with \"_HEAD\" as branch names. Opinions?\n\nHmm. It seems like the symbolic ref is the culprit, not just HEAD. The\nHEAD thing is the most likely, of course, but I could do something like:\n\n git symbolic-ref refs/remotes/origin/convenient-alias \\\n refs/remotes/origin/some-name-you-dont-like\n\nwhich is basically the same as the HEAD case (except that the\n\"convenient alias\" for HEAD is \"origin\" and not\n\"origin/convenient-alias\" due to the lookup table in dwim_ref).\n\nNow imagine the remote creates a branch called convenient-alias. When I\nfetch, am I corrupting my local tracking branches by falsely equating\nthe two? And/or when I push, am I then corrupting the remote?\n\nSo I wonder if the safety valve here should be about symbolic refs, and\nnot about the special name HEAD. Maybe we should not follow symbolic\nrefs during fetch. So if we are fetching the refspec \"foo:bar\", and the\nRHS \"bar\" is a symref, we should _not_ follow it, but instead just\noverwrite the symref with a regular ref.\n\nFor pushing, one rule could be to allow pushing from a named symref, but\nnot allow the matching rules to use a symref as a source. So I could do:\n\n git push origin convenient-alias:new-name\n\nbut\n\n git push origin\n\nwould never overwrite upstream's convenient-alias.\n\nI dunno. That's just off the top of my head, so maybe I'm missing some\ncorner cases. I would be tempted to put the push rule into receive-pack,\nso it could look at the local refs, but I don't think receive-pack has\nany way of knowing what is a symref and what is not on the pushing end.\n\n-Peff\n"},{"id":"159718","messageId":"7vbp3bqmiy.fsf@alter.siamese.dyndns.org","threadId":"26292","inReplyTo":"20110120203840.GA11468@sigill.intra.peff.net","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-01-20T21:43:17Z","receivedAt":"2011-01-20T21:43:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Hmm. It seems like the symbolic ref is the culprit, not just HEAD. The\n> HEAD thing is the most likely, of course, but I could do something like:\n>\n> git symbolic-ref refs/remotes/origin/convenient-alias \\\n> refs/remotes/origin/some-name-you-dont-like\n\nIsn't it already wrong to do the above locally, in the sense that it is\nequally wrong to do this?\n\n git update-ref refs/remotes/origin/no-such-thing-exists-over-there \n \trefs/heads/master\n\nI agree that the symbolic ref is the real source of confusion in Stephen's\ncase (I admit that I was scratching my head chasing a non-existent bug in\ntransport_update_tracking_ref() before I realized what was happening), but\nthe usual (and the only) way for refs/remotes hierarchy to get a symbolic\nref is via a normal clone, and HEAD is the only name that can cause this\nconflict. Creating a branch called HEAD (or FETCH_HEAD for that matter)\nis infinitely more likely to be a mistake than being clever, I think.\n\n> ... Maybe we should not follow symbolic\n> refs during fetch. So if we are fetching the refspec \"foo:bar\", and the\n> RHS \"bar\" is a symref, we should _not_ follow it, but instead just\n> overwrite the symref with a regular ref.\n> \n> For pushing, one rule could be to allow pushing from a named symref, but\n> not allow the matching rules to use a symref as a source....\n\nI personally like this line of thought, especially as a thought experiment\nto see what corner cases we could find, but I doubt I will be able to say\nwe covered all the corner cases with confidence without thinking long and\nvery hard. For now, I do not find this issue worth spending that kind of\ndeep thinking, especially when a lot simpler and easier to explain\nworkaround is available, but others may disagree and perfect your idea.\n"},{"id":"159719","messageId":"20110120215456.GB11468@sigill.intra.peff.net","threadId":"26292","inReplyTo":"7vbp3bqmiy.fsf@alter.siamese.dyndns.org","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-01-20T21:54:57Z","receivedAt":"2011-01-20T21:54:57Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jan 20, 2011 at 01:43:17PM -0800, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > Hmm. It seems like the symbolic ref is the culprit, not just HEAD. The\n> > HEAD thing is the most likely, of course, but I could do something like:\n> >\n> > git symbolic-ref refs/remotes/origin/convenient-alias \\\n> > refs/remotes/origin/some-name-you-dont-like\n> \n> Isn't it already wrong to do the above locally, in the sense that it is\n> equally wrong to do this?\n\nProbably. My argument in favor would be \"that is what we are doing with\nremotes/*/HEAD\", but I think the logic is somewhat circular there.\n\nThinking on it more, yeah, if you want \"convenient-alias\", you are\nprobably better off to do:\n\n git symbolic-ref refs/convenient-alias refs/remotes/origin/whatever\n\n> git update-ref refs/remotes/origin/no-such-thing-exists-over-there \n> \trefs/heads/master\n\nActually, don't we end up with that in the case of upstream deleting a\nref? Which isn't to say it isn't a stupid thing to do, but that we can\nand do get into that state.\n\nThinking on it even more, I don't think we can cover all of the weird\n\"you have a ref named $foo and they suddenly created a ref named $foo\"\npush corner cases. There is no substitution for actual communication and\norganization of ref names if you are going to be pushing along with\nother people into a central repo. Because fundamentally the ref name is\nthe unique identifier, and matching refs during push tries to reconcile\nmatches based on those identifiers.\n\n> I personally like this line of thought, especially as a thought experiment\n> to see what corner cases we could find, but I doubt I will be able to say\n> we covered all the corner cases with confidence without thinking long and\n> very hard. For now, I do not find this issue worth spending that kind of\n> deep thinking, especially when a lot simpler and easier to explain\n> workaround is available, but others may disagree and perfect your idea.\n\nYeah, after reading your response and considering a bit, I think the\nsimple \"don't make HEAD\" thing (or at least \"don't pull or push HEAD\")\nis a sane workaround.\n\n-Peff\n"},{"id":"159723","messageId":"AANLkTikBbSt5_WdbuE8a96w1pWBCYLNjMCUCBThjdLdG@mail.gmail.com","threadId":"26292","inReplyTo":"20110120215456.GB11468@sigill.intra.peff.net","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2011-01-20T23:52:03Z","receivedAt":"2011-01-20T23:52:03Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\nOn Thu, Jan 20, 2011 at 11:54 PM, Jeff King wrote:\n> On Thu, Jan 20, 2011 at 01:43:17PM -0800, Junio C Hamano wrote:\n>> I personally like this line of thought, especially as a thought experiment\n>> to see what corner cases we could find, but I doubt I will be able to say\n>> we covered all the corner cases with confidence without thinking long and\n>> very hard.  For now, I do not find this issue worth spending that kind of\n>> deep thinking, especially when a lot simpler and easier to explain\n>> workaround is available, but others may disagree and perfect your idea.\n>\n> Yeah, after reading your response and considering a bit, I think the\n> simple \"don't make HEAD\" thing (or at least \"don't pull or push HEAD\")\n> is a sane workaround.\n\nI don't fully understand the issue, so excuse me if this is totally\nwrong, but wouldn't a rule like 'you can't create a branch for which\nthere's already a symbolic ref' do the trick?\n\n-- \nFelipe Contreras\n"},{"id":"159762","messageId":"7vk4hyp38i.fsf@alter.siamese.dyndns.org","threadId":"26292","inReplyTo":"AANLkTikBbSt5_WdbuE8a96w1pWBCYLNjMCUCBThjdLdG@mail.gmail.com","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-01-21T17:37:33Z","receivedAt":"2011-01-21T17:37:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> I don't fully understand the issue, so excuse me if this is totally\n> wrong, but wouldn't a rule like 'you can't create a branch for which\n> there's already a symbolic ref' do the trick?\n\nBut whose symbolic ref are you checking against? Your own, or ones in\nsomebody else's repository that you haven't recently updated from?\n"},{"id":"159787","messageId":"AANLkTikmbWkpjioARZrmySpLM8t7kqCX0v1+NKibk_ar@mail.gmail.com","threadId":"26292","inReplyTo":"7vk4hyp38i.fsf@alter.siamese.dyndns.org","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2011-01-22T12:46:40Z","receivedAt":"2011-01-22T12:46:40Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Jan 21, 2011 at 7:37 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> I don't fully understand the issue, so excuse me if this is totally\n>> wrong, but wouldn't a rule like 'you can't create a branch for which\n>> there's already a symbolic ref' do the trick?\n>\n> But whose symbolic ref are you checking against?  Your own, or ones in\n> somebody else's repository that you haven't recently updated from?\n\nThe local ones. That means that somebody can't create a 'HEAD' branch\nlocally, and can't push a 'HEAD' branch either, as the remote server\nwould already have a 'HEAD' symbolic link. And actually, if for some\nreason I have a FOO_HEAD, and I fetch a branch called bob/FOO_HEAD,\nobviously the local symbolic ref without namespace should take\nprecedence.\n\n-- \nFelipe Contreras\n"},{"id":"161758","messageId":"AANLkTinRcmevXz3zV0wtxd7+Q3F4zcH2AZOQk1XVxYXa@mail.gmail.com","threadId":"26292","inReplyTo":"AANLkTikmbWkpjioARZrmySpLM8t7kqCX0v1+NKibk_ar@mail.gmail.com","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Stephen Kelly","fromEmail":"steveire@gmail.com","sentAt":"2011-02-20T13:17:50Z","receivedAt":"2011-02-20T13:17:50Z","isPatch":false,"sender":{"key":"steveire@gmail.com","avatar":null},"body":"bump.\n\nI don't think this issue was fixed, was it?\n\n(no need to put kdepim back in the cc list)\n\nOn Sat, Jan 22, 2011 at 1:46 PM, Felipe Contreras\n wrote:\n> On Fri, Jan 21, 2011 at 7:37 PM, Junio C Hamano wrote:\n>> Felipe Contreras writes:\n>>\n>>> I don't fully understand the issue, so excuse me if this is totally\n>>> wrong, but wouldn't a rule like 'you can't create a branch for which\n>>> there's already a symbolic ref' do the trick?\n>>\n>> But whose symbolic ref are you checking against?  Your own, or ones in\n>> somebody else's repository that you haven't recently updated from?\n>\n> The local ones. That means that somebody can't create a 'HEAD' branch\n> locally, and can't push a 'HEAD' branch either, as the remote server\n> would already have a 'HEAD' symbolic link. And actually, if for some\n> reason I have a FOO_HEAD, and I fetch a branch called bob/FOO_HEAD,\n> obviously the local symbolic ref without namespace should take\n> precedence.\n>\n> --\n> Felipe Contreras\n>\n"},{"id":"166374","messageId":"BANLkTim1gW_L-9DKo9p_VFQFUBUGWAPxoA@mail.gmail.com","threadId":"26292","inReplyTo":"AANLkTinRcmevXz3zV0wtxd7+Q3F4zcH2AZOQk1XVxYXa@mail.gmail.com","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Stephen Kelly","fromEmail":"steveire@gmail.com","sentAt":"2011-04-26T12:09:04Z","receivedAt":"2011-04-26T12:09:04Z","isPatch":false,"sender":{"key":"steveire@gmail.com","avatar":null},"body":"Can git have a bug tracker please?\n\nThis is another reminder to fix this bug which is otherwise untrackable.\n\nThanks,\n\nSteve.\n\nOn Sun, Feb 20, 2011 at 2:17 PM, Stephen Kelly wrote:\n> bump.\n>\n> I don't think this issue was fixed, was it?\n>\n> (no need to put kdepim back in the cc list)\n>\n> On Sat, Jan 22, 2011 at 1:46 PM, Felipe Contreras\n> wrote:\n>> On Fri, Jan 21, 2011 at 7:37 PM, Junio C Hamano wrote:\n>>> Felipe Contreras writes:\n>>>\n>>>> I don't fully understand the issue, so excuse me if this is totally\n>>>> wrong, but wouldn't a rule like 'you can't create a branch for which\n>>>> there's already a symbolic ref' do the trick?\n>>>\n>>> But whose symbolic ref are you checking against?  Your own, or ones in\n>>> somebody else's repository that you haven't recently updated from?\n>>\n>> The local ones. That means that somebody can't create a 'HEAD' branch\n>> locally, and can't push a 'HEAD' branch either, as the remote server\n>> would already have a 'HEAD' symbolic link. And actually, if for some\n>> reason I have a FOO_HEAD, and I fetch a branch called bob/FOO_HEAD,\n>> obviously the local symbolic ref without namespace should take\n>> precedence.\n>>\n>> --\n>> Felipe Contreras\n>>\n>\n"},{"id":"166406","messageId":"BANLkTinKDHM-RU2wqZECFcjQEoRWADnTGQ@mail.gmail.com","threadId":"26292","inReplyTo":"BANLkTim1gW_L-9DKo9p_VFQFUBUGWAPxoA@mail.gmail.com","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2011-04-26T18:18:58Z","receivedAt":"2011-04-26T18:18:58Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Apr 26, 2011 at 3:09 PM, Stephen Kelly wrote:\n> Can git have a bug tracker please?\n\nSo that you would feel comfortable that there would be a bug report\ngathering dust? Or that it's closed as invalid for lack of\ninformation?\n\n> This is another reminder to fix this bug which is otherwise untrackable.\n\nLet's imagine you are posting this to bugzilla: first question?\nHow do you reproduce this?\n\nBut I already asked you this[1], and you didn't reply. What should one\nassume but that you don't care enough to help get this fixed.\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/165320\n\n-- \nFelipe Contreras\n"},{"id":"166488","messageId":"BANLkTimFas5YLt37RLuCppkQ4ZGhmj56Cg@mail.gmail.com","threadId":"26292","inReplyTo":"BANLkTinKDHM-RU2wqZECFcjQEoRWADnTGQ@mail.gmail.com","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Stephen Kelly","fromEmail":"steveire@gmail.com","sentAt":"2011-04-27T09:18:36Z","receivedAt":"2011-04-27T09:18:36Z","isPatch":false,"sender":{"key":"steveire@gmail.com","avatar":null},"body":"On Tue, Apr 26, 2011 at 8:18 PM, Felipe Contreras\n wrote:\n> On Tue, Apr 26, 2011 at 3:09 PM, Stephen Kelly wrote:\n>> Can git have a bug tracker please?\n>\n> So that you would feel comfortable that there would be a bug report\n> gathering dust? Or that it's closed as invalid for lack of\n> information?\n\nIf you believe that it is a foregone conclusion that that is the fate\nof all bug trackers, and that that's a reasonable reason for git not\nto have one, then you have had very different experiences to me.\n\nI don't think there's more I can say than that.\n\n>\n>> This is another reminder to fix this bug which is otherwise untrackable.\n>\n> Let's imagine you are posting this to bugzilla: first question?\n> How do you reproduce this?\n\nMy initial mail illustrated the problem as best I could:\n\nhttp://thread.gmane.org/gmane.comp.kde.devel.pim/29534\n\n>\n> But I already asked you this[1], and you didn't reply. What should one\n> assume but that you don't care enough to help get this fixed.\n>\n> [1] http://article.gmane.org/gmane.comp.version-control.git/165320\n\nSomeone else replied. Isn't that enough?\n\nOther git developers confirmed it's probably an issue. Isn't that enough?\n\nhttp://thread.gmane.org/gmane.comp.kde.devel.pim/29534/focus=165326\n\nAnyway, we've had a work around in place since January. From the git\nPOV, this just falls through the cracks. Consider the bug marked as\ncan not reproduce/needs info/whatever you prefer. I'm outie.\n\nSteve.\n"},{"id":"166491","messageId":"BANLkTinkR+jEKkno30fiHBZ-PMVvvv7FxQ@mail.gmail.com","threadId":"26292","inReplyTo":"BANLkTimFas5YLt37RLuCppkQ4ZGhmj56Cg@mail.gmail.com","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2011-04-27T09:48:56Z","receivedAt":"2011-04-27T09:48:56Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Apr 27, 2011 at 12:18 PM, Stephen Kelly wrote:\n> On Tue, Apr 26, 2011 at 8:18 PM, Felipe Contreras\n> wrote:\n>> On Tue, Apr 26, 2011 at 3:09 PM, Stephen Kelly wrote:\n>>> Can git have a bug tracker please?\n>>\n>> So that you would feel comfortable that there would be a bug report\n>> gathering dust? Or that it's closed as invalid for lack of\n>> information?\n>\n> If you believe that it is a foregone conclusion that that is the fate\n> of all bug trackers, and that that's a reasonable reason for git not\n> to have one, then you have had very different experiences to me.\n>\n> I don't think there's more I can say than that.\n>\n>>\n>>> This is another reminder to fix this bug which is otherwise untrackable.\n>>\n>> Let's imagine you are posting this to bugzilla: first question?\n>> How do you reproduce this?\n>\n> My initial mail illustrated the problem as best I could:\n>\n> http://thread.gmane.org/gmane.comp.kde.devel.pim/29534\n\nNo problems here:\n\nInitialized empty Git repository in /tmp/remote/\nCloning into alice...\ndone.\nwarning: You appear to have cloned an empty repository.\n[master (root-commit) 6983153] w\n 1 files changed, 1 insertions(+), 0 deletions(-)\n create mode 100644 file\nCounting objects: 3, done.\nWriting objects: 100% (3/3), 213 bytes, done.\nTotal 3 (delta 0), reused 0 (delta 0)\nUnpacking objects: 100% (3/3), done.\nTo /tmp/remote/\n * [new branch] master -> master\n[master 116a225] w\n 1 files changed, 1 insertions(+), 0 deletions(-)\nCounting objects: 5, done.\nWriting objects: 100% (3/3), 242 bytes, done.\nTotal 3 (delta 0), reused 0 (delta 0)\nUnpacking objects: 100% (3/3), done.\nTo /tmp/remote/\n * [new branch] HEAD -> HEAD\nEverything up-to-date\nCloning into bob...\ndone.\nFrom /tmp/remote\n 6983153..116a225 HEAD -> origin/HEAD\nCurrent branch master is up to date.\n[master 0951422] w\n 1 files changed, 1 insertions(+), 0 deletions(-)\nCounting objects: 5, done.\nWriting objects: 100% (3/3), 242 bytes, done.\nTotal 3 (delta 0), reused 0 (delta 0)\nUnpacking objects: 100% (3/3), done.\nTo /tmp/remote\n 6983153..0951422 HEAD -> master\nFrom /tmp/remote\n + 0951422...116a225 HEAD -> origin/HEAD (forced update)\nAlready up-to-date.\nFrom /tmp/remote\n + 116a225...0951422 master -> origin/master (forced update)\nAlready up-to-date.\nFrom /tmp/remote\n + 0951422...116a225 HEAD -> origin/HEAD (forced update)\nAlready up-to-date.\n\n>> But I already asked you this[1], and you didn't reply. What should one\n>> assume but that you don't care enough to help get this fixed.\n>>\n>> [1] http://article.gmane.org/gmane.comp.version-control.git/165320\n>\n> Someone else replied. Isn't that enough?\n\nWith a different issue that's not really important.\n\n> Other git developers confirmed it's probably an issue. Isn't that enough?\n>\n> http://thread.gmane.org/gmane.comp.kde.devel.pim/29534/focus=165326\n\n_probably_, many things have happened since then.\n\nIs it still an issue? Doesn't seem so.\n\n-- \nFelipe Contreras\n"},{"id":"166503","messageId":"BANLkTi=DgXrWZ0ObBYi2mgk-+8w8iXM7VQ@mail.gmail.com","threadId":"26292","inReplyTo":"BANLkTinkR+jEKkno30fiHBZ-PMVvvv7FxQ@mail.gmail.com","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Stephen Kelly","fromEmail":"steveire@gmail.com","sentAt":"2011-04-27T11:29:50Z","receivedAt":"2011-04-27T11:29:50Z","isPatch":false,"sender":{"key":"steveire@gmail.com","avatar":null},"body":"On Wed, Apr 27, 2011 at 11:48 AM, Felipe Contreras\n wrote:\n> No problems here:\n\nI had another go.\n\nmkdir remote\ncd remote/\ngit init --bare\ncd ../\ngit clone remote/ alice\ncd alice/\necho test >> file\ngit add file\ngit commit -am w\ngit push origin master\necho test >> file\ngit commit -am w\ngit branch HEAD\ngit push origin HEAD\ngit push\ncd ..\ngit clone remote bob\ncd bob/\ngit branch\ngit pull --rebase\necho test >> file\ngit commit -am w\ngit push\ngit pull\ngit pull\ngit pull\necho test >> file\ngit commit -am w\ngit push\ncd ../alice\ngit branch\ngit status\necho test >> file\ngit commit -am w\ngit push\necho test2 >> file\ngit commit -am w\ngit push\ngit pull\necho test3 >> file\ngit commit -am w\ngit status\ngit push\ngitk\n\n\nstephen@bishop:/tmp/git$ mkdir remote\n\nstephen@bishop:/tmp/git$ cd remote/\n\nstephen@bishop:/tmp/git/remote$ git init --bare\nInitialized empty Git repository in /tmp/git/remote/\n\nstephen@bishop:/tmp/git/remote$ cd ../\n\nstephen@bishop:/tmp/git$ git clone remote/ alice\nCloning into alice...\ndone.\nwarning: You appear to have cloned an empty repository.\n\nstephen@bishop:/tmp/git$ cd alice/\n\nstephen@bishop:/tmp/git/alice$ echo test >> file\n\nstephen@bishop:/tmp/git/alice$ git add file\n\nstephen@bishop:/tmp/git/alice$ git commit -am w\n[master (root-commit) 072df32] w\n 1 files changed, 1 insertions(+), 0 deletions(-)\n create mode 100644 file\n\nstephen@bishop:/tmp/git/alice{master}$ git push origin master\nCounting objects: 3, done.\nWriting objects: 100% (3/3), 210 bytes, done.\nTotal 3 (delta 0), reused 0 (delta 0)\nUnpacking objects: 100% (3/3), done.\nTo /tmp/git/remote/\n * [new branch] master -> master\n\nstephen@bishop:/tmp/git/alice{master}$ echo test >> file\n\nstephen@bishop:/tmp/git/alice{master}$ git commit -am w\n[master b39d099] w\n 1 files changed, 1 insertions(+), 0 deletions(-)\n\nstephen@bishop:/tmp/git/alice{master}$ git branch HEAD\n\nstephen@bishop:/tmp/git/alice{master}$ git push origin HEAD\nCounting objects: 5, done.\nWriting objects: 100% (3/3), 242 bytes, done.\nTotal 3 (delta 0), reused 0 (delta 0)\nUnpacking objects: 100% (3/3), done.\nTo /tmp/git/remote/\n * [new branch] HEAD -> HEAD\n\nstephen@bishop:/tmp/git/alice{master}$ git push\nEverything up-to-date\n\nstephen@bishop:/tmp/git/alice{master}$ cd ..\n\nstephen@bishop:/tmp/git$ git clone remote bob\nCloning into bob...\ndone.\n\nstephen@bishop:/tmp/git$ cd bob/\n\nstephen@bishop:/tmp/git/bob{master}$ git pull --rebase\nFrom /tmp/git/remote\n 072df32..b39d099 HEAD -> origin/HEAD\nCurrent branch master is up to date.\n\nstephen@bishop:/tmp/git/bob{master}$ echo test >> file\n\nstephen@bishop:/tmp/git/bob{master}$ git commit -am w\n[master b39d099] w\n 1 files changed, 1 insertions(+), 0 deletions(-)\n\nstephen@bishop:/tmp/git/bob{master}$ git push\nTotal 0 (delta 0), reused 0 (delta 0)\nTo /tmp/git/remote\n 072df32..b39d099 HEAD -> master\n\nstephen@bishop:/tmp/git/bob{master}$ git pull\nCurrent branch master is up to date.\n\nstephen@bishop:/tmp/git/bob{master}$ git pull\nCurrent branch master is up to date.\n\nstephen@bishop:/tmp/git/bob{master}$ git pull\nCurrent branch master is up to date.\n\nstephen@bishop:/tmp/git/bob{master}$ echo test >> file\n\nstephen@bishop:/tmp/git/bob{master}$ git commit -am w\n[master 47699a9] w\n 1 files changed, 1 insertions(+), 0 deletions(-)\n\nstephen@bishop:/tmp/git/bob{master}$ git push\nCounting objects: 5, done.\nWriting objects: 100% (3/3), 240 bytes, done.\nTotal 3 (delta 0), reused 0 (delta 0)\nUnpacking objects: 100% (3/3), done.\nTo /tmp/git/remote\n b39d099..47699a9 HEAD -> master\n\nstephen@bishop:/tmp/git/bob{master}$ cd ../alice\n\nstephen@bishop:/tmp/git/alice{master}$ git branch\n HEAD\n* master\n\nstephen@bishop:/tmp/git/alice{master}$ git status\nwarning: refname 'HEAD' is ambiguous.\nwarning: refname 'HEAD' is ambiguous.\n# On branch master\n# Your branch is ahead of 'origin/master' by 1 commit.\n#\nnothing to commit (working directory clean)\n\nstephen@bishop:/tmp/git/alice{master}$ echo test >> file\n\nstephen@bishop:/tmp/git/alice{master}$ git commit -am w\nwarning: refname 'HEAD' is ambiguous.\nwarning: refname 'HEAD' is ambiguous.\nwarning: refname 'HEAD' is ambiguous.\n[master 7e83bed] w\n 1 files changed, 1 insertions(+), 0 deletions(-)\n\nstephen@bishop:/tmp/git/alice{master}$ git push\nEverything up-to-date\n\nstephen@bishop:/tmp/git/alice{master}$ echo test2 >> file\n\nstephen@bishop:/tmp/git/alice{master}$ git commit -am w\nwarning: refname 'HEAD' is ambiguous.\nwarning: refname 'HEAD' is ambiguous.\nwarning: refname 'HEAD' is ambiguous.\n[master b4f5b5b] w\n 1 files changed, 1 insertions(+), 0 deletions(-)\n\nstephen@bishop:/tmp/git/alice{master}$ git push\nEverything up-to-date\n\nstephen@bishop:/tmp/git/alice{master}$ git pull\nwarning: refname 'HEAD' is ambiguous.\nwarning: refname 'HEAD' is ambiguous.\nwarning: refname 'HEAD' is ambiguous.\nwarning: refname 'HEAD' is ambiguous.\nremote: Counting objects: 5, done.\nremote: Total 3 (delta 0), reused 0 (delta 0)\nUnpacking objects: 100% (3/3), done.\nFrom /tmp/git/remote\n 072df32..47699a9 master -> origin/master\nwarning: refname 'HEAD' is ambiguous.\nwarning: refname 'HEAD' is ambiguous.\nwarning: refname 'HEAD' is ambiguous.\nFirst, rewinding head to replay your work on top of it...\nwarning: refname 'HEAD' is ambiguous.\nwarning: refname 'HEAD' is ambiguous.\nApplying: w\nwarning: refname 'HEAD' is ambiguous.\nwarning: refname 'HEAD' is ambiguous.\n\nstephen@bishop:/tmp/git/alice{master}$ echo test3 >> file\n\nstephen@bishop:/tmp/git/alice{master}$ git commit -am w\nwarning: refname 'HEAD' is ambiguous.\nwarning: refname 'HEAD' is ambiguous.\nwarning: refname 'HEAD' is ambiguous.\n[master cc2088e] w\n 1 files changed, 1 insertions(+), 0 deletions(-)\n\nstephen@bishop:/tmp/git/alice{master}$ git status\nwarning: refname 'HEAD' is ambiguous.\nwarning: refname 'HEAD' is ambiguous.\n# On branch master\n# Your branch is ahead of 'origin/master' by 2 commits.\n#\nnothing to commit (working directory clean)\n\nstephen@bishop:/tmp/git/alice{master}$ git push\nEverything up-to-date\n\nstephen@bishop:/tmp/git/alice{master}$\n\nstephen@bishop:/tmp/git/alice{master}$ git --version\ngit version 1.7.4.1\n"},{"id":"166504","messageId":"BANLkTi=-d+8ynv5NQ1SZA3V7PMiGiHauCw@mail.gmail.com","threadId":"26292","inReplyTo":"BANLkTi=DgXrWZ0ObBYi2mgk-+8w8iXM7VQ@mail.gmail.com","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2011-04-27T11:32:20Z","receivedAt":"2011-04-27T11:32:20Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Apr 27, 2011 at 2:29 PM, Stephen Kelly wrote:\n> On Wed, Apr 27, 2011 at 11:48 AM, Felipe Contreras\n> wrote:\n>> No problems here:\n>\n> I had another go.\n\nAnd is that the expected behavior or not? BTW. I used 1.7.5.\n\n-- \nFelipe Contreras\n"},{"id":"166505","messageId":"BANLkTikCQkt+e-kA2hbtMh+OFqrrZHt-NQ@mail.gmail.com","threadId":"26292","inReplyTo":"BANLkTi=-d+8ynv5NQ1SZA3V7PMiGiHauCw@mail.gmail.com","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Stephen Kelly","fromEmail":"steveire@gmail.com","sentAt":"2011-04-27T11:37:23Z","receivedAt":"2011-04-27T11:37:23Z","isPatch":false,"sender":{"key":"steveire@gmail.com","avatar":null},"body":"It is not expected.\n\nAlices repo is fubar'd. gitk doesn't work. The info about master being\nahead of remote etc is wrong or git push tells me it worked, though it\ndoesn't seem to.\n\n\n\nstephen@bishop:/tmp/git/alice{master}$ git status\nwarning: refname 'HEAD' is ambiguous.\nwarning: refname 'HEAD' is ambiguous.\n# On branch master\n# Your branch is ahead of 'origin/master' by 2 commits.\n#\nnothing to commit (working directory clean)\n\nstephen@bishop:/tmp/git/alice{master}$ git push\nEverything up-to-date\n\nstephen@bishop:/tmp/git/alice{master}$ git status\nwarning: refname 'HEAD' is ambiguous.\nwarning: refname 'HEAD' is ambiguous.\n# On branch master\n# Your branch is ahead of 'origin/master' by 2 commits.\n#\nnothing to commit (working directory clean)\n\n\nOn Wed, Apr 27, 2011 at 1:32 PM, Felipe Contreras\n wrote:\n> On Wed, Apr 27, 2011 at 2:29 PM, Stephen Kelly wrote:\n>> On Wed, Apr 27, 2011 at 11:48 AM, Felipe Contreras\n>> wrote:\n>>> No problems here:\n>>\n>> I had another go.\n>\n> And is that the expected behavior or not? BTW. I used 1.7.5.\n>\n> --\n> Felipe Contreras\n>\n"},{"id":"166512","messageId":"BANLkTimLnggco_+mQZ2_T_myAHsDD-=g1w@mail.gmail.com","threadId":"26292","inReplyTo":"BANLkTi=DgXrWZ0ObBYi2mgk-+8w8iXM7VQ@mail.gmail.com","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2011-04-27T12:21:35Z","receivedAt":"2011-04-27T12:21:35Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Wed, Apr 27, 2011 at 1:29 PM, Stephen Kelly wrote:\n> On Wed, Apr 27, 2011 at 11:48 AM, Felipe Contreras\n> wrote:\n>> No problems here:\n>\n> I had another go.\n>\n> mkdir remote\n> cd remote/\n> git init --bare\n> cd ../\n> git clone remote/ alice\n> cd alice/\n> echo test >> file\n> git add file\n> git commit -am w\n> git push origin master\n> echo test >> file\n> git commit -am w\n> git branch HEAD\n\nI'll stop you here. You reproduce the issue a lot simpler:\n\ngit init foo &&\ncd foo &&\necho \"foo\" > bar &&\ngit add bar &&\ngit commit -m. &&\ngit branch HEAD &&\ngitk\n\nNo need to involve remote branches. While remote branches makes the\nissue worse, because you can get in a situation where gitk doesn't\nwhen someone else made a nasty branch, and you fetched it.\n\nThe real problem is that \"git rev-parse HEAD\" outputs \"warning:\nrefname 'HEAD' is ambiguous.\" to stderr (even if stderr is a non-tty),\nand gitk does not like that.\n\nThis can be fixed by either doing \"git -c core.warnambiguousrefs=0\nrev-parse HEAD\", which strikes me as ugly, or by making sure that we\ndon't issue this warning when not attached to a tty:\n\ndiff --git a/sha1_name.c b/sha1_name.c\nindex faea58d..c7e855e 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -391,7 +391,7 @@ static int get_sha1_basic(const char *str, int\nlen, unsigned char *sha1)\n \tif (!refs_found)\n \t\treturn -1;\n\n-\tif (warn_ambiguous_refs && refs_found > 1)\n+\tif (warn_ambiguous_refs && refs_found > 1 && isatty(2))\n \t\twarning(warn_msg, len, str);\n\n \tif (reflog_len) {\n"},{"id":"166514","messageId":"BANLkTi=pPtsRMbJpgqMZy0Qq+HqT0uR_wQ@mail.gmail.com","threadId":"26292","inReplyTo":"BANLkTikCQkt+e-kA2hbtMh+OFqrrZHt-NQ@mail.gmail.com","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2011-04-27T12:26:00Z","receivedAt":"2011-04-27T12:26:00Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Apr 27, 2011 at 2:37 PM, Stephen Kelly wrote:\n> It is not expected.\n>\n> Alices repo is fubar'd. gitk doesn't work. The info about master being\n> ahead of remote etc is wrong or git push tells me it worked, though it\n> doesn't seem to.\n\ngitk --all works fine, and gitk show a precise warning explaining the problem.\n\nAlso, the 'git push' worked fine. Perhaps what you didn't expect is\nthat when push.default=current, instead of pushing the current branch,\nthe 'HEAD' branch is being pushed.\n\nSo the test can be simplified to:\n\nmkdir remote\ncd remote/\ngit init --bare\ncd ../\ngit clone remote/ alice\ncd alice/\necho test >> file\ngit add file\ngit commit -am w\ngit push origin master\necho test >> file\ngit commit -am w\ngit branch HEAD\ngit push origin HEAD\ngit -c push.default=current push\ngit diff master origin/master\n\nAnd the diff should be empty. With that in mind, it should be easy to\ncreate a test script that does something similar, and add it to the\nsuite.\n\n-- \nFelipe Contreras\n"},{"id":"166518","messageId":"BANLkTikxS-_9h4rBdbbJ2e-RkjMWyiC1Mg@mail.gmail.com","threadId":"26292","inReplyTo":"BANLkTimLnggco_+mQZ2_T_myAHsDD-=g1w@mail.gmail.com","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2011-04-27T12:49:47Z","receivedAt":"2011-04-27T12:49:47Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Wed, Apr 27, 2011 at 2:21 PM, Erik Faye-Lund wrote:\n> On Wed, Apr 27, 2011 at 1:29 PM, Stephen Kelly wrote:\n>> On Wed, Apr 27, 2011 at 11:48 AM, Felipe Contreras\n>> wrote:\n>>> No problems here:\n>>\n>> I had another go.\n>>\n>> mkdir remote\n>> cd remote/\n>> git init --bare\n>> cd ../\n>> git clone remote/ alice\n>> cd alice/\n>> echo test >> file\n>> git add file\n>> git commit -am w\n>> git push origin master\n>> echo test >> file\n>> git commit -am w\n>> git branch HEAD\n>\n> I'll stop you here. You reproduce the issue a lot simpler:\n>\n> git init foo &&\n> cd foo &&\n> echo \"foo\" > bar &&\n> git add bar &&\n> git commit -m. &&\n> git branch HEAD &&\n> gitk\n>\n> No need to involve remote branches. While remote branches makes the\n> issue worse, because you can get in a situation where gitk doesn't\n> when someone else made a nasty branch, and you fetched it.\n>\n> The real problem is that \"git rev-parse HEAD\" outputs \"warning:\n> refname 'HEAD' is ambiguous.\" to stderr (even if stderr is a non-tty),\n> and gitk does not like that.\n>\n> This can be fixed by either doing \"git -c core.warnambiguousrefs=0\n> rev-parse HEAD\", which strikes me as ugly, or by making sure that we\n> don't issue this warning when not attached to a tty:\n\nOf course, a third (and probably even better) option is to make gitk\nwarn about the ambiguous refname (like other commands will), but not\ntreat it as a fatal problem. But I'm not motivated enough to give that\nsolution a stab myself.\n\nNot outputting that warning might be a regression for other users of\nrev-parse (and/or the underlying mechanics).\n"},{"id":"166899","messageId":"BANLkTinqxy6jCJLNVPKmMW3CErbfN7Hm=g@mail.gmail.com","threadId":"26292","inReplyTo":"BANLkTikxS-_9h4rBdbbJ2e-RkjMWyiC1Mg@mail.gmail.com","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Stephen Kelly","fromEmail":"steveire@gmail.com","sentAt":"2011-05-02T19:26:35Z","receivedAt":"2011-05-02T19:26:35Z","isPatch":false,"sender":{"key":"steveire@gmail.com","avatar":null},"body":"On Wed, Apr 27, 2011 at 2:49 PM, Erik Faye-Lund wrote:\n> On Wed, Apr 27, 2011 at 2:21 PM, Erik Faye-Lund wrote:\n>> On Wed, Apr 27, 2011 at 1:29 PM, Stephen Kelly wrote:\n>>> On Wed, Apr 27, 2011 at 11:48 AM, Felipe Contreras\n>>> wrote:\n>>>> No problems here:\n>>>\n>>> I had another go.\n>>>\n>>> mkdir remote\n>>> cd remote/\n>>> git init --bare\n>>> cd ../\n>>> git clone remote/ alice\n>>> cd alice/\n>>> echo test >> file\n>>> git add file\n>>> git commit -am w\n>>> git push origin master\n>>> echo test >> file\n>>> git commit -am w\n>>> git branch HEAD\n>>\n>> I'll stop you here. You reproduce the issue a lot simpler:\n>>\n>> git init foo &&\n>> cd foo &&\n>> echo \"foo\" > bar &&\n>> git add bar &&\n>> git commit -m. &&\n>> git branch HEAD &&\n>> gitk\n>>\n>> No need to involve remote branches. While remote branches makes the\n>> issue worse, because you can get in a situation where gitk doesn't\n>> when someone else made a nasty branch, and you fetched it.\n>>\n>> The real problem is that \"git rev-parse HEAD\" outputs \"warning:\n>> refname 'HEAD' is ambiguous.\" to stderr (even if stderr is a non-tty),\n>> and gitk does not like that.\n>>\n>> This can be fixed by either doing \"git -c core.warnambiguousrefs=0\n>> rev-parse HEAD\", which strikes me as ugly, or by making sure that we\n>> don't issue this warning when not attached to a tty:\n>\n> Of course, a third (and probably even better) option is to make gitk\n> warn about the ambiguous refname (like other commands will), but not\n> treat it as a fatal problem. But I'm not motivated enough to give that\n> solution a stab myself.\n>\n> Not outputting that warning might be a regression for other users of\n> rev-parse (and/or the underlying mechanics).\n>\n\nOk, if you can't see in the code why a branch called HEAD might\ncorrupt the remote and I can't demonstrate it with a testcase, maybe\nit's not an issue anymore, I don't know.\n\nHopefully the relevant people saw the side issues brought up such as\nthis ambiguous ref issue. After all, there's no other way to track\nthose issues.\n\nThanks for the investigation and help,\n\nSteve.\n"},{"id":"166903","messageId":"BANLkTinJvt=Nnt8YG-D1wpWKbBei+m+4XA@mail.gmail.com","threadId":"26292","inReplyTo":"BANLkTinqxy6jCJLNVPKmMW3CErbfN7Hm=g@mail.gmail.com","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2011-05-02T19:43:05Z","receivedAt":"2011-05-02T19:43:05Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Mon, May 2, 2011 at 9:26 PM, Stephen Kelly wrote:\n> On Wed, Apr 27, 2011 at 2:49 PM, Erik Faye-Lund wrote:\n>> On Wed, Apr 27, 2011 at 2:21 PM, Erik Faye-Lund wrote:\n>>> On Wed, Apr 27, 2011 at 1:29 PM, Stephen Kelly wrote:\n>>>> On Wed, Apr 27, 2011 at 11:48 AM, Felipe Contreras\n>>>> wrote:\n>>>>> No problems here:\n>>>>\n>>>> I had another go.\n>>>>\n>>>> mkdir remote\n>>>> cd remote/\n>>>> git init --bare\n>>>> cd ../\n>>>> git clone remote/ alice\n>>>> cd alice/\n>>>> echo test >> file\n>>>> git add file\n>>>> git commit -am w\n>>>> git push origin master\n>>>> echo test >> file\n>>>> git commit -am w\n>>>> git branch HEAD\n>>>\n>>> I'll stop you here. You reproduce the issue a lot simpler:\n>>>\n>>> git init foo &&\n>>> cd foo &&\n>>> echo \"foo\" > bar &&\n>>> git add bar &&\n>>> git commit -m. &&\n>>> git branch HEAD &&\n>>> gitk\n>>>\n>>> No need to involve remote branches. While remote branches makes the\n>>> issue worse, because you can get in a situation where gitk doesn't\n>>> when someone else made a nasty branch, and you fetched it.\n>>>\n>>> The real problem is that \"git rev-parse HEAD\" outputs \"warning:\n>>> refname 'HEAD' is ambiguous.\" to stderr (even if stderr is a non-tty),\n>>> and gitk does not like that.\n>>>\n>>> This can be fixed by either doing \"git -c core.warnambiguousrefs=0\n>>> rev-parse HEAD\", which strikes me as ugly, or by making sure that we\n>>> don't issue this warning when not attached to a tty:\n>>\n>> Of course, a third (and probably even better) option is to make gitk\n>> warn about the ambiguous refname (like other commands will), but not\n>> treat it as a fatal problem. But I'm not motivated enough to give that\n>> solution a stab myself.\n>>\n>> Not outputting that warning might be a regression for other users of\n>> rev-parse (and/or the underlying mechanics).\n>>\n>\n> Ok, if you can't see in the code why a branch called HEAD might\n> corrupt the remote and I can't demonstrate it with a testcase, maybe\n> it's not an issue anymore, I don't know.\n>\n\nNo, it's still an issue, and I believe I pin-pointed it in my first\nmail. You can try out the patch I sent, and see if that helps in your\ncase. If it does, I think it'd make sense to do something (preferably\na bit more robust) with it.\n"},{"id":"166954","messageId":"BANLkTinCSotWC-kbPDJc57NZM29hizYKpA@mail.gmail.com","threadId":"26292","inReplyTo":"BANLkTinJvt=Nnt8YG-D1wpWKbBei+m+4XA@mail.gmail.com","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2011-05-03T17:54:54Z","receivedAt":"2011-05-03T17:54:54Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, May 2, 2011 at 10:43 PM, Erik Faye-Lund wrote:\n> On Mon, May 2, 2011 at 9:26 PM, Stephen Kelly wrote:\n>> On Wed, Apr 27, 2011 at 2:49 PM, Erik Faye-Lund wrote:\n>>> On Wed, Apr 27, 2011 at 2:21 PM, Erik Faye-Lund wrote:\n>>>> On Wed, Apr 27, 2011 at 1:29 PM, Stephen Kelly wrote:\n>>>>> On Wed, Apr 27, 2011 at 11:48 AM, Felipe Contreras\n>>>>> wrote:\n>>>>>> No problems here:\n>>>>>\n>>>>> I had another go.\n>>>>>\n>>>>> mkdir remote\n>>>>> cd remote/\n>>>>> git init --bare\n>>>>> cd ../\n>>>>> git clone remote/ alice\n>>>>> cd alice/\n>>>>> echo test >> file\n>>>>> git add file\n>>>>> git commit -am w\n>>>>> git push origin master\n>>>>> echo test >> file\n>>>>> git commit -am w\n>>>>> git branch HEAD\n>>>>\n>>>> I'll stop you here. You reproduce the issue a lot simpler:\n>>>>\n>>>> git init foo &&\n>>>> cd foo &&\n>>>> echo \"foo\" > bar &&\n>>>> git add bar &&\n>>>> git commit -m. &&\n>>>> git branch HEAD &&\n>>>> gitk\n>>>>\n>>>> No need to involve remote branches. While remote branches makes the\n>>>> issue worse, because you can get in a situation where gitk doesn't\n>>>> when someone else made a nasty branch, and you fetched it.\n>>>>\n>>>> The real problem is that \"git rev-parse HEAD\" outputs \"warning:\n>>>> refname 'HEAD' is ambiguous.\" to stderr (even if stderr is a non-tty),\n>>>> and gitk does not like that.\n>>>>\n>>>> This can be fixed by either doing \"git -c core.warnambiguousrefs=0\n>>>> rev-parse HEAD\", which strikes me as ugly, or by making sure that we\n>>>> don't issue this warning when not attached to a tty:\n>>>\n>>> Of course, a third (and probably even better) option is to make gitk\n>>> warn about the ambiguous refname (like other commands will), but not\n>>> treat it as a fatal problem. But I'm not motivated enough to give that\n>>> solution a stab myself.\n>>>\n>>> Not outputting that warning might be a regression for other users of\n>>> rev-parse (and/or the underlying mechanics).\n>>>\n>>\n>> Ok, if you can't see in the code why a branch called HEAD might\n>> corrupt the remote and I can't demonstrate it with a testcase, maybe\n>> it's not an issue anymore, I don't know.\n>>\n>\n> No, it's still an issue, and I believe I pin-pointed it in my first\n> mail. You can try out the patch I sent, and see if that helps in your\n> case. If it does, I think it'd make sense to do something (preferably\n> a bit more robust) with it.\n\nYes, I think your patch should be applied regardless, as that solves\n_one_ issue.\n\nBut there are other issues.\n\n-- \nFelipe Contreras\n"},{"id":"166956","messageId":"BANLkTimHfH-o6Fyoo61xVFxAhELNmD=4xg@mail.gmail.com","threadId":"26292","inReplyTo":"BANLkTinCSotWC-kbPDJc57NZM29hizYKpA@mail.gmail.com","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Stephen Kelly","fromEmail":"steveire@gmail.com","sentAt":"2011-05-03T18:08:49Z","receivedAt":"2011-05-03T18:08:49Z","isPatch":false,"sender":{"key":"steveire@gmail.com","avatar":null},"body":"On Tue, May 3, 2011 at 7:54 PM, Felipe Contreras\n wrote:\n> On Mon, May 2, 2011 at 10:43 PM, Erik Faye-Lund wrote:\n>> No, it's still an issue, and I believe I pin-pointed it in my first\n>> mail. You can try out the patch I sent, and see if that helps in your\n>> case. If it does, I think it'd make sense to do something (preferably\n>> a bit more robust) with it.\n\nI don't have a build of git at the moment to test it as I'm using\ndistro packages again. The only test case I have is the alice and bob\nstuff already posted, so if your patch fixes that for you that's good\nenough from my POV.\n\n>\n> Yes, I think your patch should be applied regardless, as that solves\n> _one_ issue.\n>\n> But there are other issues.\n>\n\nAll the best,\n\nSteve.\n"},{"id":"166962","messageId":"BANLkTik18oTdNa1A99QAXJ9vz105jC3gLA@mail.gmail.com","threadId":"26292","inReplyTo":"BANLkTimHfH-o6Fyoo61xVFxAhELNmD=4xg@mail.gmail.com","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2011-05-03T19:20:32Z","receivedAt":"2011-05-03T19:20:32Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, May 3, 2011 at 9:08 PM, Stephen Kelly wrote:\n> On Tue, May 3, 2011 at 7:54 PM, Felipe Contreras\n> wrote:\n>> On Mon, May 2, 2011 at 10:43 PM, Erik Faye-Lund wrote:\n>>> No, it's still an issue, and I believe I pin-pointed it in my first\n>>> mail. You can try out the patch I sent, and see if that helps in your\n>>> case. If it does, I think it'd make sense to do something (preferably\n>>> a bit more robust) with it.\n>\n> I don't have a build of git at the moment to test it as I'm using\n> distro packages again. The only test case I have is the alice and bob\n> stuff already posted, so if your patch fixes that for you that's good\n> enough from my POV.\n\nAs I said, 'gitk --all' works fine, the patch would fix 'gitk'.\n\n-- \nFelipe Contreras\n"},{"id":"167016","messageId":"BANLkTinLCirA4XP9AOb9piGo9ucMsmrmkQ@mail.gmail.com","threadId":"26292","inReplyTo":"BANLkTinCSotWC-kbPDJc57NZM29hizYKpA@mail.gmail.com","subject":"Re: Creating remote branch called HEAD corrupts remote clones","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2011-05-04T12:35:30Z","receivedAt":"2011-05-04T12:35:30Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Tue, May 3, 2011 at 7:54 PM, Felipe Contreras\n wrote:\n> On Mon, May 2, 2011 at 10:43 PM, Erik Faye-Lund wrote:\n>> On Mon, May 2, 2011 at 9:26 PM, Stephen Kelly wrote:\n>>> Ok, if you can't see in the code why a branch called HEAD might\n>>> corrupt the remote and I can't demonstrate it with a testcase, maybe\n>>> it's not an issue anymore, I don't know.\n>>\n>> No, it's still an issue, and I believe I pin-pointed it in my first\n>> mail. You can try out the patch I sent, and see if that helps in your\n>> case. If it does, I think it'd make sense to do something (preferably\n>> a bit more robust) with it.\n>\n> Yes, I think your patch should be applied regardless, as that solves\n> _one_ issue.\n\nOK, I'll send out an RFC with some discussion on the alternatives a bit later.\n\n> But there are other issues.\n\nI guess the root of the problem(s) is that there's no way to\ndisambiguate 'HEAD'. One solution could be to say that 'HEAD' never is\nambiguous, but it feels a little inconsistent... Thoughts, anyone?\n"},{"id":"167469","messageId":"1304927478-3112-1-git-send-email-kusmabite@gmail.com","threadId":"26292","inReplyTo":"BANLkTinLCirA4XP9AOb9piGo9ucMsmrmkQ@mail.gmail.com","subject":"[PATCH] only warn about ambiguous refs if stderr is a tty","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2011-05-09T07:51:18Z","receivedAt":"2011-05-09T07:51:18Z","isPatch":true,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"If there's a branch (either local or remote) called 'HEAD'\ncommands that take a ref currently emits a warning, no matter\nif the output is going to a TTY or not.\n\nFix this by making sure we only output this warning when stderr\nis a TTY. Other git commands or scripts should not care about\nthis ambiguity.\n\nThis fix prevents gitk from barfing when given no arguments and\nthere's a branch called 'HEAD'.\n\nSigned-off-by: Erik Faye-Lund \n\n---\n\nIn 2f8acdb ('core.warnambiguousrefs: warns when \"name\" is used\nand both \"name\" branch and tag exists.'), a check for collisions\nof refs was introduced. It does not seem to me like the intention\nwas to check HEAD for ambiguty (because the commit talks about\nbranches and tags), but it does.\n\nBecause HEAD cannot be disambiguated like branches and tags can,\nthis can lead to an annoying warning, or even an error in the case\nof gitk.\n\nA branch called HEAD can be 'injected' into another user's repo\nthrough remotes, and this can cause annoyance (and in the case of\ngitk, brokenness) just by pulling the wrong remote. Yuck.\n\nThe particular problem of gitk can be fixed by making gitk able\nto parse the warning, and probably forwarding it to the user.\nThis strikes me as The Right Thing To Do(tm), but is outside of my\ngitk and TCL/TK skills.\n\nAlternatively, gitk could state that it doesn't care about\nambiguous refs, by calling 'git -c core.warnambiguousrefs=0\nshow-ref '.\n\nOne question is if ANY warnings should be output to stderr if it's\nnot a TTY. My guess is that there probably are some classes of\nwarnings that should, but the vast majority should probably not.\n\nPerhaps it's better to make warning() filter the output if stderr\nis not a tty instead, and make the places that needs to warn just\ndo fprintf(stderr, ...) instead? That's one huge hammer, though.\n\nAnother question is if we should come up with a way of\ndisambiguating HEAD. Perhaps having something like 'refs/HEAD'\nwill do?\n\nSo, to recap: The way I see it, these are our options:\n\n 1) Discard this specific warning when stderr isn't a TTY (i.e\n what this patch does)\n 2) Discard all warnings when stderr isn't a TTY\n 3) Make gitk understand and forward warnings to the user\n 4) Have gitk explicitly ignore ambiuous refs\n 5) Come up with a way to disambiguate HEAD, and use that instead\n by default\n 6) Force HEAD to never be ambiguous\n 7) Leave things as they are\n\nI think 3) + 5) might be the most sane solution. That way we\ninform the user that there's an ambiguity if he or she runs\n'gitk HEAD' (so he or she has a chance the chance to correct it),\nbut the correct HEAD is chosen (without any annoying warnings) if\nthe user didn't specify a ref.\n\nThis combination also relies on us NOT doing 1), 2) or 4); i.e the\nwarning must still be output to reach the user.\n\nThoughs?\n\n sha1_name.c | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/sha1_name.c b/sha1_name.c\nindex faea58d..c7e855e 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -391,7 +391,7 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)\n \tif (!refs_found)\n \t\treturn -1;\n \n-\tif (warn_ambiguous_refs && refs_found > 1)\n+\tif (warn_ambiguous_refs && refs_found > 1 && isatty(2))\n \t\twarning(warn_msg, len, str);\n \n \tif (reflog_len) {\n-- \n1.7.5.3775.ga8770a\n"},{"id":"167471","messageId":"20110509080315.GA6205@sigill.intra.peff.net","threadId":"26292","inReplyTo":"1304927478-3112-1-git-send-email-kusmabite@gmail.com","subject":"Re: [PATCH] only warn about ambiguous refs if stderr is a tty","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-09T08:03:15Z","receivedAt":"2011-05-09T08:03:15Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 09, 2011 at 09:51:18AM +0200, Erik Faye-Lund wrote:\n\n> If there's a branch (either local or remote) called 'HEAD'\n> commands that take a ref currently emits a warning, no matter\n> if the output is going to a TTY or not.\n> \n> Fix this by making sure we only output this warning when stderr\n> is a TTY. Other git commands or scripts should not care about\n> this ambiguity.\n> \n> This fix prevents gitk from barfing when given no arguments and\n> there's a branch called 'HEAD'.\n\nThis feels wrong. Gitk should not care about messages on stderr, for\nexactly the reason that they may be harmless warnings (if anything, it\nshould show them to the user in a dialog).\n\nMy understanding is that this is a tcl thing, but I just think it's\ninsane.\n\n> In 2f8acdb ('core.warnambiguousrefs: warns when \"name\" is used\n> and both \"name\" branch and tag exists.'), a check for collisions\n> of refs was introduced. It does not seem to me like the intention\n> was to check HEAD for ambiguty (because the commit talks about\n> branches and tags), but it does.\n> \n> Because HEAD cannot be disambiguated like branches and tags can,\n> this can lead to an annoying warning, or even an error in the case\n> of gitk.\n\nThis is a separate issue, isn't it? Gitk should probably handle\nambiguous ref warnings better, no matter what the name. And if\nambiguous HEAD warnings are considered too annoying, they should be\nsquelched for everyone. I don't personally have an opinion on the\nlatter, though.\n\n> A branch called HEAD can be 'injected' into another user's repo\n> through remotes, and this can cause annoyance (and in the case of\n> gitk, brokenness) just by pulling the wrong remote. Yuck.\n\nCan you give an example? If I am fetching your refs into\nrefs/remotes/$remote/*, how does that create an ambiguity?\n\n> The particular problem of gitk can be fixed by making gitk able\n> to parse the warning, and probably forwarding it to the user.\n> This strikes me as The Right Thing To Do(tm), but is outside of my\n> gitk and TCL/TK skills.\n\nAgreed. And also outside my tcl skills. :)\n\n> One question is if ANY warnings should be output to stderr if it's\n> not a TTY. My guess is that there probably are some classes of\n> warnings that should, but the vast majority should probably not.\n\nI disagree. If I do:\n\n git foo 2>errors\n\nI would certainly expect any relevant errors to end up in that file. As\nfor why I would do that, two cases I can think of offhand are:\n\n 1. Test scripts, which use this extensively.\n\n 2. Sometimes cron jobs will capture chatty output in a file and show\n it only in the case of some error condition.\n\n> Another question is if we should come up with a way of\n> disambiguating HEAD. Perhaps having something like 'refs/HEAD'\n> will do?\n\nYeah, if we disambiguate, I would be tempted to say that \"HEAD\" always\nunambiguously refers to \"HEAD\". And \"refs/HEAD\" should already\nwork, no?\n\n> So, to recap: The way I see it, these are our options:\n> \n> 1) Discard this specific warning when stderr isn't a TTY (i.e\n> what this patch does)\n> 2) Discard all warnings when stderr isn't a TTY\n> 3) Make gitk understand and forward warnings to the user\n> 4) Have gitk explicitly ignore ambiuous refs\n> 5) Come up with a way to disambiguate HEAD, and use that instead\n> by default\n> 6) Force HEAD to never be ambiguous\n> 7) Leave things as they are\n\n> \n> I think 3) + 5) might be the most sane solution.\n\nAgreed.\n\n> diff --git a/sha1_name.c b/sha1_name.c\n> index faea58d..c7e855e 100644\n> --- a/sha1_name.c\n> +++ b/sha1_name.c\n> @@ -391,7 +391,7 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)\n> \tif (!refs_found)\n> \t\treturn -1;\n> \n> -\tif (warn_ambiguous_refs && refs_found > 1)\n> +\tif (warn_ambiguous_refs && refs_found > 1 && isatty(2))\n> \t\twarning(warn_msg, len, str);\n> \n\nI think I have made it clear that I am not in favor of this approach,\nbut if we were to do it, it is too late to be calling isatty(2) here.\nYou need to also check pager_in_use(), as we may have redirected stderr\ninto the pager's pipe.\n\n-Peff\n"},{"id":"167476","messageId":"BANLkTimR_S-px-MfRy0pKGrjxOgSC_=e=A@mail.gmail.com","threadId":"26292","inReplyTo":"20110509080315.GA6205@sigill.intra.peff.net","subject":"Re: [PATCH] only warn about ambiguous refs if stderr is a tty","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2011-05-09T08:41:02Z","receivedAt":"2011-05-09T08:41:02Z","isPatch":true,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Mon, May 9, 2011 at 10:03 AM, Jeff King wrote:\n> On Mon, May 09, 2011 at 09:51:18AM +0200, Erik Faye-Lund wrote:\n>\n>> If there's a branch (either local or remote) called 'HEAD'\n>> commands that take a ref currently emits a warning, no matter\n>> if the output is going to a TTY or not.\n>>\n>> Fix this by making sure we only output this warning when stderr\n>> is a TTY. Other git commands or scripts should not care about\n>> this ambiguity.\n>>\n>> This fix prevents gitk from barfing when given no arguments and\n>> there's a branch called 'HEAD'.\n>\n> This feels wrong. Gitk should not care about messages on stderr, for\n> exactly the reason that they may be harmless warnings (if anything, it\n> should show them to the user in a dialog).\n\nI agree.\n\n>> In 2f8acdb ('core.warnambiguousrefs: warns when \"name\" is used\n>> and both \"name\" branch and tag exists.'), a check for collisions\n>> of refs was introduced. It does not seem to me like the intention\n>> was to check HEAD for ambiguty (because the commit talks about\n>> branches and tags), but it does.\n>>\n>> Because HEAD cannot be disambiguated like branches and tags can,\n>> this can lead to an annoying warning, or even an error in the case\n>> of gitk.\n>\n> This is a separate issue, isn't it? Gitk should probably handle\n> ambiguous ref warnings better, no matter what the name.  And if\n> ambiguous HEAD warnings are considered too annoying, they should be\n> squelched for everyone. I don't personally have an opinion on the\n> latter, though.\n>\n\nI agree; it's possible to squelch them already with the\ncore.warnambiguousrefs config, so people who want to live with\nbranched called 'HEAD' can already get around it.\n\n>> A branch called HEAD can be 'injected' into another user's repo\n>> through remotes, and this can cause annoyance (and in the case of\n>> gitk, brokenness) just by pulling the wrong remote. Yuck.\n>\n> Can you give an example? If I am fetching your refs into\n> refs/remotes/$remote/*, how does that create an ambiguity?\n>\n\nActually, this is just something I read out of Stephen's report and\nwas too lazy to double check. It's not possible to do, because\nrefs/remotes/* does not seem to be checked for ambiguity. Thanks for\nsetting me straight :)\n\n>> One question is if ANY warnings should be output to stderr if it's\n>> not a TTY. My guess is that there probably are some classes of\n>> warnings that should, but the vast majority should probably not.\n>\n> I disagree. If I do:\n>\n>  git foo 2>errors\n>\n> I would certainly expect any relevant errors to end up in that file. As\n> for why I would do that, two cases I can think of offhand are:\n>\n>  1. Test scripts, which use this extensively.\n>\n>  2. Sometimes cron jobs will capture chatty output in a file and show\n>     it only in the case of some error condition.\n>\n\nI was talking about warnings, not errors. But I can also see that one\nwould sometimes want warnings even when not connected to a tty, but\nperhaps only when -v is specified?\n\n>> Another question is if we should come up with a way of\n>> disambiguating HEAD. Perhaps having something like 'refs/HEAD'\n>> will do?\n>\n> Yeah, if we disambiguate, I would be tempted to say that \"HEAD\" always\n> unambiguously refers to \"HEAD\".\n\nWhile that would touch less code, my gut tells me it's a bit more\nfragile. But perhaps you're right; I can't come up with any real\narguments (i.e use cases that I care about) on top of my head.\n\n> And \"refs/HEAD\" should already work, no?\n\nNo:\n$ git init foo\n$ cd foo/\n$ echo \"foo\" > bar\n$ git add bar\n$ git commit -m.\n[master (root-commit) fc0cbef] .\nwarning: LF will be replaced by CRLF in bar.\nThe file will have its original line endings in your working directory.\n 1 files changed, 1 insertions(+), 0 deletions(-)\n create mode 100644 bar\n$ git show refs/HEAD\nfatal: ambiguous argument 'refs/HEAD': unknown revision or path not in\nthe working tree.\nUse '--' to separate paths from revisions\n\n>> diff --git a/sha1_name.c b/sha1_name.c\n>> index faea58d..c7e855e 100644\n>> --- a/sha1_name.c\n>> +++ b/sha1_name.c\n>> @@ -391,7 +391,7 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)\n>>       if (!refs_found)\n>>               return -1;\n>>\n>> -     if (warn_ambiguous_refs && refs_found > 1)\n>> +     if (warn_ambiguous_refs && refs_found > 1 && isatty(2))\n>>               warning(warn_msg, len, str);\n>>\n>\n> I think I have made it clear that I am not in favor of this approach,\n> but if we were to do it, it is too late to be calling isatty(2) here.\n> You need to also check pager_in_use(), as we may have redirected stderr\n> into the pager's pipe.\n\nGood point. I doubt I'll update the patch in this direction though,\nsince I agree it's not the right approach.\n"},{"id":"167482","messageId":"20110509103208.GA9060@sigill.intra.peff.net","threadId":"26292","inReplyTo":"BANLkTimR_S-px-MfRy0pKGrjxOgSC_=e=A@mail.gmail.com","subject":"Re: [PATCH] only warn about ambiguous refs if stderr is a tty","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-09T10:32:08Z","receivedAt":"2011-05-09T10:32:08Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 09, 2011 at 10:41:02AM +0200, Erik Faye-Lund wrote:\n\n> > I disagree. If I do:\n> >\n> >  git foo 2>errors\n> >\n> > I would certainly expect any relevant errors to end up in that file. As\n> > for why I would do that, two cases I can think of offhand are:\n> >\n> >  1. Test scripts, which use this extensively.\n> >\n> >  2. Sometimes cron jobs will capture chatty output in a file and show\n> >     it only in the case of some error condition.\n> >\n> \n> I was talking about warnings, not errors. But I can also see that one\n> would sometimes want warnings even when not connected to a tty, but\n> perhaps only when -v is specified?\n\nI know. I meant a script like this:\n\n cat >>foo.sh <<'EOF'\n # go to branch in question\n git checkout \"$1\"\n\n # note some point of interest\n sha1=`git rev-parse \"$2\"`\n\n # do some script-specific inspection of $sha1, and\n # merge if it looks OK\n if test -z \"$(git log ..$sha1 -- some-path)\"; then\n git merge $sha1 || exit 1\n fi\n EOF\n\nIt may produce some chatty output (like \"switched to branch...\"). So I\nredirect it to a file, and if everything is successful, that output is\nuninteresting. But if it fails, then I want to see everything. So I do\nsomething like:\n\n if ! foo.sh master topic >output.tmp 2>&1; then\n cat output.tmp\n exit 1\n fi\n\nIf the merge fails, it will produce an error message. But I _also_ want\nto see any warnings that were generated by it and earlier commands, like\nrev-parse (e.g., an ambiguous ref warning might help us understand why\nthe merge failed).\n\nObviously this is a pretty trivial example that I cooked up for this\nemail. But the concept of stash-stderr-and-report-on-error is a pretty\ncommon pattern for cron jobs.\n\n> > Yeah, if we disambiguate, I would be tempted to say that \"HEAD\" always\n> > unambiguously refers to \"HEAD\".\n> \n> While that would touch less code, my gut tells me it's a bit more\n> fragile. But perhaps you're right; I can't come up with any real\n> arguments (i.e use cases that I care about) on top of my head.\n\nHonestly, I'm kind of surprised it's not that way already. It would make\nsense to me that \"upper\" levels would take precedence over lower levels,\nbut that ambiguity would occur within a level. So if I say \"foo\", we\nwould look for:\n\n 1. $GIT_DIR/foo, with no ambiguity\n\n 2. $GIT_DIR/refs/foo, with no ambiguity\n\n 3. $GIT_DIR/refs/tags/foo\n $GIT_DIR/refs/heads/foo\n $GIT_DIR/refs/remotes/foo\n\n And note any ambiguity between those three.\n\nWhich is not very different than what we do today, except that things\nlike HEAD and FETCH_HEAD would always be unambiguously about the\ntop-level.\n\n> > And \"refs/HEAD\" should already work, no?\n> \n> No:\n> $ git init foo\n> $ cd foo/\n> $ echo \"foo\" > bar\n> $ git add bar\n> $ git commit -m.\n> [master (root-commit) fc0cbef] .\n> warning: LF will be replaced by CRLF in bar.\n> The file will have its original line endings in your working directory.\n> 1 files changed, 1 insertions(+), 0 deletions(-)\n> create mode 100644 bar\n> $ git show refs/HEAD\n> fatal: ambiguous argument 'refs/HEAD': unknown revision or path not in\n> the working tree.\n> Use '--' to separate paths from revisions\n\nOf course, because there is no refs/HEAD at all. I meant \"if you have\nambiguity between $GIT_DIR/HEAD and $GIT_DIR/refs/HEAD\", then saying\n\"refs/HEAD\" should disambiguate already. In your example, there is no\nambiguity.\n\nWhat I failed to notice is that the likely disambiguator is actually\n\"refs/heads/HEAD\" if you erroneously made a branch.\n\nTry this:\n\n # A repo with two commits\n git init repo && cd repo &&\n echo content >file &&\n git add file &&\n git commit -m one &&\n echo content >>file &&\n git commit -a -m two &&\n\n # And an ambiguously named ref called HEAD, pointing to \"one\";\n # our real HEAD is still pointing to \"two\"\n git branch HEAD HEAD^ &&\n\n # This should warn of ambiguity, but show \"two\"\n git log -1 --oneline HEAD\n\n # And this should not be ambiguous at all, and show \"one\"\n git log -1 --oneline refs/heads/HEAD\n\n # You can even do the same thing with refs/HEAD if you want, but\n # you have to use plumbing to get such a ref.\n git branch -d HEAD\n git update-ref refs/HEAD HEAD^\n\n # same as before, ambiguous \"two\"\n git log -1 --oneline HEAD\n\n # or we can use refs/HEAD to get \"one\"\n git log -1 --oneline refs/HEAD\n\nSo most of that makes sense to me. We choose $GIT_DIR/HEAD over other\noptions, and you can specifically refer to something further down by\nits fully-qualified name.\n\nThe only thing that I think we might want to change is that \"HEAD\" is\nconsidered ambiguous with \"refs/heads/HEAD\". On the other hand, it seems\na little insane to name your branch that, given that it has a\nwell-established meaning in git. I admit I haven't been following this\nthread too closely. What is the reason not to tell the user \"sorry, that\nis an insane branch name. Accept the ambiguity warning, or choose a\ndifferent name\"?\n\n-Peff\n"},{"id":"167493","messageId":"BANLkTimn7542tji-Uu5iH72HS9fcnaywvg@mail.gmail.com","threadId":"26292","inReplyTo":"20110509103208.GA9060@sigill.intra.peff.net","subject":"Re: [PATCH] only warn about ambiguous refs if stderr is a tty","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2011-05-09T12:37:48Z","receivedAt":"2011-05-09T12:37:48Z","isPatch":true,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Mon, May 9, 2011 at 12:32 PM, Jeff King wrote:\n> On Mon, May 09, 2011 at 10:41:02AM +0200, Erik Faye-Lund wrote:\n>> I was talking about warnings, not errors. But I can also see that one\n>> would sometimes want warnings even when not connected to a tty, but\n>> perhaps only when -v is specified?\n>\n> I know. I meant a script like this:\n>\n>  cat >>foo.sh <<'EOF'\n>  # go to branch in question\n>  git checkout \"$1\"\n>\n>  # note some point of interest\n>  sha1=`git rev-parse \"$2\"`\n>\n>  # do some script-specific inspection of $sha1, and\n>  # merge if it looks OK\n>  if test -z \"$(git log ..$sha1 -- some-path)\"; then\n>    git merge $sha1 || exit 1\n>  fi\n>  EOF\n>\n> It may produce some chatty output (like \"switched to branch...\"). So I\n> redirect it to a file, and if everything is successful, that output is\n> uninteresting. But if it fails, then I want to see everything. So I do\n> something like:\n>\n>  if ! foo.sh master topic >output.tmp 2>&1; then\n>    cat output.tmp\n>    exit 1\n>  fi\n>\n> If the merge fails, it will produce an error message. But I _also_ want\n> to see any warnings that were generated by it and earlier commands, like\n> rev-parse (e.g., an ambiguous ref warning might help us understand why\n> the merge failed).\n\nYeah, I understood that part. My point was that once the output is\nwanted for diagnostics, you probably also want verbose output. And\nwarnings should probably always be output if we're verbose.\n\nBut I have no strong feelings about this, so it's probably better to\nleave it alone.\n\n>> > Yeah, if we disambiguate, I would be tempted to say that \"HEAD\" always\n>> > unambiguously refers to \"HEAD\".\n>>\n>> While that would touch less code, my gut tells me it's a bit more\n>> fragile. But perhaps you're right; I can't come up with any real\n>> arguments (i.e use cases that I care about) on top of my head.\n>\n> Honestly, I'm kind of surprised it's not that way already. It would make\n> sense to me that \"upper\" levels would take precedence over lower levels,\n> but that ambiguity would occur within a level. So if I say \"foo\", we\n> would look for:\n>\n>  1. $GIT_DIR/foo, with no ambiguity\n>\n>  2. $GIT_DIR/refs/foo, with no ambiguity\n>\n>  3. $GIT_DIR/refs/tags/foo\n>     $GIT_DIR/refs/heads/foo\n>     $GIT_DIR/refs/remotes/foo\n>\n>     And note any ambiguity between those three.\n>\n> Which is not very different than what we do today, except that things\n> like HEAD and FETCH_HEAD would always be unambiguously about the\n> top-level.\n>\n\nI think that would make sense.\n\n>> > And \"refs/HEAD\" should already work, no?\n>>\n>> No:\n>> $ git init foo\n>> $ cd foo/\n>> $ echo \"foo\" > bar\n>> $ git add bar\n>> $ git commit -m.\n>> [master (root-commit) fc0cbef] .\n>> warning: LF will be replaced by CRLF in bar.\n>> The file will have its original line endings in your working directory.\n>>  1 files changed, 1 insertions(+), 0 deletions(-)\n>>  create mode 100644 bar\n>> $ git show refs/HEAD\n>> fatal: ambiguous argument 'refs/HEAD': unknown revision or path not in\n>> the working tree.\n>> Use '--' to separate paths from revisions\n>\n> Of course, because there is no refs/HEAD at all. I meant \"if you have\n> ambiguity between $GIT_DIR/HEAD and $GIT_DIR/refs/HEAD\", then saying\n> \"refs/HEAD\" should disambiguate already. In your example, there is no\n> ambiguity.\n\nI meant that \"refs/HEAD\" could be an non-ambiguous alias for HEAD, but\nit's probably easier to just say that 'HEAD' isn't ambiguous. Your\nsuggestion of only checking for ambiguousness on the same level is IMO\nan elegant way of doing this.\n\n> What I failed to notice is that the likely disambiguator is actually\n> \"refs/heads/HEAD\" if you erroneously made a branch.\n>\n> Try this:\n>\n>  # A repo with two commits\n>  git init repo && cd repo &&\n>  echo content >file &&\n>  git add file &&\n>  git commit -m one &&\n>  echo content >>file &&\n>  git commit -a -m two &&\n>\n>  # And an ambiguously named ref called HEAD, pointing to \"one\";\n>  # our real HEAD is still pointing to \"two\"\n>  git branch HEAD HEAD^ &&\n>\n>  # This should warn of ambiguity, but show \"two\"\n>  git log -1 --oneline HEAD\n>\n>  # And this should not be ambiguous at all, and show \"one\"\n>  git log -1 --oneline refs/heads/HEAD\n>\n>  # You can even do the same thing with refs/HEAD if you want, but\n>  # you have to use plumbing to get such a ref.\n>  git branch -d HEAD\n>  git update-ref refs/HEAD HEAD^\n>\n>  # same as before, ambiguous \"two\"\n>  git log -1 --oneline HEAD\n>\n>  # or we can use refs/HEAD to get \"one\"\n>  git log -1 --oneline refs/HEAD\n>\n> So most of that makes sense to me. We choose $GIT_DIR/HEAD over other\n> options, and you can specifically refer to something further down by\n> its fully-qualified name.\n>\n> The only thing that I think we might want to change is that \"HEAD\" is\n> considered ambiguous with \"refs/heads/HEAD\". On the other hand, it seems\n> a little insane to name your branch that, given that it has a\n> well-established meaning in git.\n\nI agree. There could be a remote chance that you can get a branch\ncalled 'HEAD' from some foreign vcs or something, though. But I don't\nthink it's very likely, and the problem will also go away if we go\nwith your approach mentioned above.\n\n> I admit I haven't been following this\n> thread too closely. What is the reason not to tell the user \"sorry, that\n> is an insane branch name. Accept the ambiguity warning, or choose a\n> different name\"?\n\nI think having the ambiguity warning in itself isn't the problem, it's\ngitk not swallowing it that is.\n\nThe reporter also had some problems pushing with a branch named 'HEAD'\nin his repo, but I didn't look into that part at all.\n"},{"id":"167494","messageId":"20110509124931.GA18197@sigill.intra.peff.net","threadId":"26292","inReplyTo":"BANLkTimn7542tji-Uu5iH72HS9fcnaywvg@mail.gmail.com","subject":"Re: [PATCH] only warn about ambiguous refs if stderr is a tty","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-09T12:49:31Z","receivedAt":"2011-05-09T12:49:31Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 09, 2011 at 02:37:48PM +0200, Erik Faye-Lund wrote:\n\n> Yeah, I understood that part. My point was that once the output is\n> wanted for diagnostics, you probably also want verbose output. And\n> warnings should probably always be output if we're verbose.\n\nAh, I see. I think my main concern is that the behavior you proposed\nwould simply be surprising to people used to normal unix conventions.\nBut it sounds like we both agree that isn't the right direction anyway.\n\n> > Of course, because there is no refs/HEAD at all. I meant \"if you have\n> > ambiguity between $GIT_DIR/HEAD and $GIT_DIR/refs/HEAD\", then saying\n> > \"refs/HEAD\" should disambiguate already. In your example, there is no\n> > ambiguity.\n> \n> I meant that \"refs/HEAD\" could be an non-ambiguous alias for HEAD, but\n> it's probably easier to just say that 'HEAD' isn't ambiguous. Your\n> suggestion of only checking for ambiguousness on the same level is IMO\n> an elegant way of doing this.\n\nOK, I see what you meant. But \"refs/HEAD\" cannot be a shortcut for\n\"HEAD\", as it means something totally different. You can have \"HEAD\",\n\"refs/HEAD\", \"refs/heads/HEAD\" all co-existing.\n\n> I agree. There could be a remote chance that you can get a branch\n> called 'HEAD' from some foreign vcs or something, though. But I don't\n> think it's very likely, and the problem will also go away if we go\n> with your approach mentioned above.\n\nThinking on it more, I think warning is probably the only sane thing to\ndo there. Having a branch with that name is just going to be confusing\nin the long run, and the sooner we start making the user aware of the\nsituation, the better.\n\n> > I admit I haven't been following this\n> > thread too closely. What is the reason not to tell the user \"sorry, that\n> > is an insane branch name. Accept the ambiguity warning, or choose a\n> > different name\"?\n> \n> I think having the ambiguity warning in itself isn't the problem, it's\n> gitk not swallowing it that is.\n\nAgreed.\n\n> The reporter also had some problems pushing with a branch named 'HEAD'\n> in his repo, but I didn't look into that part at all.\n\nI expect that would be a separate issue entirely (if it were fetching, I\nwouldn't be surprised if it was the \"fake\" refs/remotes/*/HEAD symref we\ncreate getting in the way).\n\n-Peff\n"},{"id":"167510","messageId":"7vmxivq1fg.fsf@alter.siamese.dyndns.org","threadId":"26292","inReplyTo":"20110509124931.GA18197@sigill.intra.peff.net","subject":"Re: [PATCH] only warn about ambiguous refs if stderr is a tty","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-09T16:33:07Z","receivedAt":"2011-05-09T16:33:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Thinking on it more, I think warning is probably the only sane thing to\n> do there. Having a branch with that name is just going to be confusing\n> in the long run, and the sooner we start making the user aware of the\n> situation, the better.\n> ...\n>> I think having the ambiguity warning in itself isn't the problem, it's\n>> gitk not swallowing it that is.\n>\n> Agreed.\n\nI agree with both of the above. It seems that the only thing we would\nneed is to do (3) and nothing else in Erik's original list?\n\n>> So, to recap: The way I see it, these are our options:\n>> \n>> 1) Discard this specific warning when stderr isn't a TTY (i.e\n>> what this patch does)\n>> 2) Discard all warnings when stderr isn't a TTY\n>> 3) Make gitk understand and forward warnings to the user\n>> 4) Have gitk explicitly ignore ambiuous refs\n>> 5) Come up with a way to disambiguate HEAD, and use that instead\n>> by default\n>> 6) Force HEAD to never be ambiguous\n>> 7) Leave things as they are\n"},{"id":"167540","messageId":"20110509220952.GD3719@sigill.intra.peff.net","threadId":"26292","inReplyTo":"7vmxivq1fg.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] only warn about ambiguous refs if stderr is a tty","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-09T22:09:52Z","receivedAt":"2011-05-09T22:09:52Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 09, 2011 at 09:33:07AM -0700, Junio C Hamano wrote:\n\n> >> I think having the ambiguity warning in itself isn't the problem, it's\n> >> gitk not swallowing it that is.\n> >\n> > Agreed.\n> \n> I agree with both of the above. It seems that the only thing we would\n> need is to do (3) and nothing else in Erik's original list?\n> [...]\n> >> 3) Make gitk understand and forward warnings to the user\n\nYeah, I think so. Now we just need a volunteer who wants to write some\ntcl. :)\n\n-Peff\n"}]}