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

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

 



I went for 3, and have sent a patch for that here - [PATCH/GSoC]
parse-options: Add a new nousage opt
However, it currently has one bug
Running 'git tag --contains qq' twice will first show an error, then
print qq, meaning that the first command creates the tag qq.
Running 'git tag -l --contains qq' works fine.
My first question is if 'git tag --contains' (without '-l') supposed to work?
If not, then I would fix that bug, otherwise fix the bug my code
introduced, and add tests for it.

-Chirayu

On Sat, Mar 19, 2016 at 11:42 PM, Jeff King <peff@xxxxxxxx> wrote:
> On Sat, Mar 19, 2016 at 11:38:09PM +0530, Chirayu Desai wrote:
>
>> > You'd teach parse_opt_commits() to store the string _name_ of the
>> > argument (e.g., using a string_list rather than a commit_list), and then
>> > later resolve those names into commits.
>> Gotcha, will need to figure out where exactly would those names be
>> resolved, can do after following the code path a bit more, can do.
>
> Without looking too closely, I suspect you could do it as the first step
> in filter_refs(). Or alternatively, add a function to "finalize" the
> filter state before making queries of it.
>
> -Peff
--
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]