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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Mar 19, 2016 at 10:19 PM, Chirayu Desai <chirayudesai1@xxxxxxxxx> wrote:
> Hi, I want to work on this as my GSoC micro project.
>
>> 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.
>> 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?

The extract that you posted isn't very clear.
I guess posting a link with the previous discussion would be quite
helpful as some people don't have the previous emails in the inbox.
The archives can be found at
http://dir.gmane.org/gmane.comp.version-control.git .
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]