Re: "git tag --contains <id>" is too chatty, if <id> is invalid

From: Chirayu Desai <chirayudesai1@gmail.com>
Date: Mar 19, 2016, 16:49 UTC
Message-ID: <CAJj6+1Fcp+Fjx9N6Mon1A5uP-_npnPL1Acu5-cR_bHVfs3EMWA@mail.gmail.com>

Hi, I want to work on this as my GSoC micro project.

Show 10 quoted lines

> On Mon, Jan 18, 2016 at 10:24:31PM +0100, Toralf Förster wrote:
> > very first line is "error: malformed object name <id>" which tells all, or ?
> Yeah, I agree that showing the "-h" help is a bit much.
> This is a side effect of looking up in the commit in the parse-options
> callback. It has to signal an error to the option parser, and then the
> option parser always shows the help on an error.
> I think we'd need to do one of:
> 1. call die() in the option-parsing callback (this is probably a bad
> precedent, as the callbacks might be reused from a place that wants
> to behave differently)

I assume you mean parse-options-cb.c:parse_opt_commits() by the callback. I see that it is currently used only by commands which have a "--with" or "--contains" option, and all of them behave the same way, printing the full usage, so a one line change in that function would fix it for all of those.

Show 5 quoted lines

> 2. have the callback just store the argument string, and then resolve
> the commit later (and die or whatever if it doesn't exist). This
> pushes more work onto the caller, but in this case it's all done by
> the ref-filter code, so it could presumably happen during another
> part of the ref-filter setup.

I'm not quire sure how exactly to do that.

> 3. teach parse-options to accept some specific non-zero return code
> that means "return an error, but don't show the usage"

This sounds good, but also the most intrusive of 3.

> I think any one of those would be a good project for somebody looking to
> get their feet wet in working on git. I think (2) is the cleanest.
> -Peff

What would be the best way to proceed with this?

Thanks, Chirayu Desai