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

From: Chirayu Desai <chirayudesai1@gmail.com>
Date: Mar 20, 2016, 06:49 UTC
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:

Show 13 quoted lines

> 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