{"thread":{"id":"17630","subject":"More noise when parsing ref args?","startedAt":"2009-02-07T15:48:19Z","lastAt":"2009-02-07T15:48:19Z","messageCount":1,"participants":["Jan Krüger"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"103633","messageId":"20090207164819.7150661a@perceptron","threadId":"17630","inReplyTo":null,"subject":"More noise when parsing ref args?","fromName":"Jan Krüger","fromEmail":"jk@jk.gs","sentAt":"2009-02-07T15:48:19Z","receivedAt":"2009-02-07T15:48:19Z","isPatch":false,"sender":{"key":"jk@jk.gs","avatar":"https://avatars.githubusercontent.com/u/1774?v=4"},"body":"Good day,\n\nI heard a (quite valid) complaint on IRC about a confusing error\nmessage. The command used was \"git show <commit>:foo\", where foo was a\nworking tree file in the CWD (a non-toplevel dir of the repository).\nObviously this couldn't have worked but the error message was the usual\n\"ambiguous argument\" message output by verify_filename(). That message\ndoesn't really make clear the fact that the commit object was found but\nthe path wasn't. It's easy for someone with less experience to read the\nmessage as \"either the <commit> or the path suffix you gave was wrong\".\n\nIt would be great adding another message that points out what exactly\nwent wrong in looking up the object, but that message would then appear\nin plumbing. So what's the policy on adding new error messages to\nplumbing? If it's a bad idea: I remember that a couple of months ago\nsome error handling code was changed to allow overloading messages from\nporcelain. Can that be extended with a reasonable amount of effort?\n\n-Jan\n"}]}