{"thread":{"id":"46230","subject":"Ambiguity warning printed twice ?","startedAt":"2017-06-22T12:47:02Z","lastAt":"2017-06-23T02:25:36Z","messageCount":3,"participants":["Kaartic Sivaraam","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"322924","messageId":"1498135581.2089.1.camel@gmail.com","threadId":"46230","inReplyTo":null,"subject":"Ambiguity warning printed twice ?","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-06-22T12:46:21Z","receivedAt":"2017-06-22T12:47:02Z","isPatch":false,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Happy day everyone,\n\nI accidentally noticed a weird behaviour of 'git status'. In a\nrepository I created a branch with the name 'HEAD' by chance. When I\nrun 'git status' in the repository it prints a warning about an\nambiguous reference about 'HEAD' which is expected but it prints it\ntwice which seems suspicious.\n\n $ git branch\n   HEAD\n   master\n * test\n\n $ git status\n warning: refname 'HEAD' is ambiguous.\n warning: refname 'HEAD' is ambiguous.\n On branch test\n ....\n\nAny reasons behind this behaviour or is this a bug?\n\n\n-- \nRegards,\nKaartic Sivaraam \n"},{"id":"322931","messageId":"20170622142348.hwlrajujgrxo6nwf@sigill.intra.peff.net","threadId":"46230","inReplyTo":"1498135581.2089.1.camel@gmail.com","subject":"Re: Ambiguity warning printed twice ?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-06-22T14:23:48Z","receivedAt":"2017-06-22T14:24:06Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jun 22, 2017 at 06:16:21PM +0530, Kaartic Sivaraam wrote:\n\n> I accidentally noticed a weird behaviour of 'git status'. In a\n> repository I created a branch with the name 'HEAD' by chance. When I\n> run 'git status' in the repository it prints a warning about an\n> ambiguous reference about 'HEAD' which is expected but it prints it\n> twice which seems suspicious.\n> \n> $ git branch\n>   HEAD\n>   master\n> * test\n> \n> $ git status\n> warning: refname 'HEAD' is ambiguous.\n> warning: refname 'HEAD' is ambiguous.\n> On branch test\n> ....\n> \n> Any reasons behind this behaviour or is this a bug?\n\nIt's not unreasonable for a complex command like git-status to need to\nresolve HEAD multiple times. You can see how we get to each case by\nrunning:\n\n gdb /path/to/git-status\n\nand then doing:\n\n break warning\n run\n\nEach time it breaks, you can run \"bt\" to get a backtrace, and then \"c\"\nto continue\".\n\nIt looks like the first one is when cmd_status() resolves the HEAD to\nsee if we are on an unborn branch, and the second is done by wt_status\nto diff the index against HEAD. It would probably be possible to feed\nthe results of the first resolution to wt-status. But that would just\nhelp this case, and I wouldn't be surprised if there are other commands\nthat do multiple resolutions (or even scripts which call multiple\ncommands).\n\nSince warning should be rare, we could keep track of which names we've\nwarned about and suppress multiple warnings. That would help\nsingle-process cases like this, but scripts which call multiple Git\ncommands would still show multiple warnings. I don't know if that's\nworth doing or not.\n\n-Peff\n"},{"id":"323049","messageId":"1498183919.1783.9.camel@gmail.com","threadId":"46230","inReplyTo":"20170622142348.hwlrajujgrxo6nwf@sigill.intra.peff.net","subject":"Re: Ambiguity warning printed twice ?","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-06-23T02:11:59Z","receivedAt":"2017-06-23T02:25:36Z","isPatch":false,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Thu, 2017-06-22 at 10:23 -0400, Jeff King wrote:\n> It's not unreasonable for a complex command like git-status to need\n> to\n> resolve HEAD multiple times. You can see how we get to each case by\n> running:\n> \n>   gdb /path/to/git-status\n> \n> and then doing:\n> \n>   break warning\n>   run\n> \n> Each time it breaks, you can run \"bt\" to get a backtrace, and then\n> \"c\"\n> to continue\".\n> \nThanks for the guidance about debugging. It was very helpful and was a\nreminder that there's a useful tool called the debugger which I have\nfailed to consider!\n\n> It looks like the first one is when cmd_status() resolves the HEAD to\n> see if we are on an unborn branch, and the second is done by\n> wt_status\n> to diff the index against HEAD. It would probably be possible to feed\n> the results of the first resolution to wt-status. But that would just\n> help this case, and I wouldn't be surprised if there are other\n> commands\n> that do multiple resolutions (or even scripts which call multiple\n> commands).\n> \n> Since warning should be rare, we could keep track of which names\n> we've\n> warned about and suppress multiple warnings. That would help\n> single-process cases like this, but scripts which call multiple Git\n> commands would still show multiple warnings. I don't know if that's\n> worth doing or not.\nI guess it's NOT. If I understood things correctly, this issue occurs\nonly if the ref 'HEAD' is ambiguous. Trying out a very approximate\ncalculation shows the probability to be some where around \"1 in the\ntrillions or quadrillions\". Further, it drops down to 0 when common\nsense is kicked-in (most people would know git uses HEAD internally).\nThus this isn't worth enough to deserve a fix except if there are\nother things that I'm missing that could spoil my calculation.\n\nAnyways, hoping some \"big\" would happen, that avoids these kind of\nissues (inherently). :)\n\n-- \nRegards,\nKaartic Sivaraam \n"}]}