{"thread":{"id":"41213","subject":"\"git tag --contains <id>\" is too chatty, if <id> is invalid","startedAt":"2016-01-18T21:24:31Z","lastAt":"2016-01-18T21:54:33Z","messageCount":2,"participants":["Toralf Förster","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"276309","messageId":"569D580F.4070302@gmx.de","threadId":"41213","inReplyTo":null,"subject":"\"git tag --contains <id>\" is too chatty, if <id> is invalid","fromName":"Toralf Förster","fromEmail":"toralf.foerster@gmx.de","sentAt":"2016-01-18T21:24:31Z","receivedAt":"2016-01-18T21:24:31Z","isPatch":false,"sender":{"key":"toralf.foerster@gmx.de","avatar":null},"body":" very first line is \"error: malformed object name <id>\" which tells all, or ?\n\n-- \nToralf, pgp: C4EACDDE 0076E94E\n"},{"id":"276314","messageId":"20160118215433.GB24136@sigill.intra.peff.net","threadId":"41213","inReplyTo":"569D580F.4070302@gmx.de","subject":"Re: \"git tag --contains <id>\" is too chatty, if <id> is invalid","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-01-18T21:54:33Z","receivedAt":"2016-01-18T21:54:33Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 18, 2016 at 10:24:31PM +0100, Toralf Förster wrote:\n\n>  very first line is \"error: malformed object name <id>\" which tells all, or ?\n\nYeah, I agree that showing the \"-h\" help is a bit much.\n\nThis is a side effect of looking up in the commit in the parse-options\ncallback. It has to signal an error to the option parser, and then the\noption parser always shows the help on an error.\n\nI think we'd need to do one of:\n\n  1. call die() in the option-parsing callback (this is probably a bad\n     precedent, as the callbacks might be reused from a place that wants\n     to behave differently)\n\n  2. have the callback just store the argument string, and then resolve\n     the commit later (and die or whatever if it doesn't exist). This\n     pushes more work onto the caller, but in this case it's all done by\n     the ref-filter code, so it could presumably happen during another\n     part of the ref-filter setup.\n\n  3. teach parse-options to accept some specific non-zero return code\n     that means \"return an error, but don't show the usage\"\n\nI think any one of those would be a good project for somebody looking to\nget their feet wet in working on git. I think (2) is the cleanest.\n\n-Peff\n"}]}