From: Chirayu Desai <chirayudesai1@gmail.com>
Date: Sun, 20 Mar 2016 06:49:46 GMT
Subject: Re: "git tag --contains <id>" is too chatty, if <id> is invalid
Message-ID: <CAJj6+1H6L=LxnDRzuC6OzXgVvzXsngGJ5X=E5Fi6Fg7JXkEJaQ@mail.gmail.com>
In-Reply-To: <20160319181228.GA9115@sigill.intra.peff.net>

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@peff.net> 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