Re: [PATCH 4/8] tag: Implicitly supply --list given another list-like option
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Mar 20, 2017, 09:16 UTC
- Message-ID
- <CACBZZX41W40PzSdxsPU+=NP==LuYdAUcD2n4Q381opn63DfcqA@mail.gmail.com>
- In-Reply-To
- <20170320035549.smzgu2jkaxrhuxl4@sigill.intra.peff.net>
On Mon, Mar 20, 2017 at 4:55 AM, Jeff King <peff@peff.net> wrote:
Show 72 quoted lines
> On Sat, Mar 18, 2017 at 10:32:52AM +0000, Ævar Arnfjörð Bjarmason wrote:
>
>> With this change errors messages such as "--contains option is only
>> allowed with -l" don't make sense anymore, since options like
>> --contain turn on -l. Instead we error out when list-like options such
>> as --contain are used in conjunction with conflicting options such as
>> -d or -v.
>
> Yeah, I think this is the right approach.
>
>> This change does not consider "-n" a list-like option, even though
>> that might be logical. Permitting it would allow:
>>
>> git tag -n 100
>>
>> As a synonym for:
>>
>> git tag -n --list 100
>>
>> Which, while not technically ambiguous as the option must already be
>> provided as -n<num> rather than -n <num>, would be confusing.
>
> I'm not sure the existing behavior isn't confusing anyway (most optional
> arguments are). But I don't mind being conservative and leaving out "-n"
> for now; we can always convert it later if somebody feels strongly about
> it.
>
>> diff --git a/builtin/tag.c b/builtin/tag.c
>> index 0bba3fd070..3483636e59 100644
>> --- a/builtin/tag.c
>> +++ b/builtin/tag.c
>> @@ -454,8 +454,12 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
>> }
>> create_tag_object = (opt.sign || annotate || msg.given || msgfile);
>>
>> - if (argc == 0 && !cmdmode && !create_tag_object)
>> - cmdmode = 'l';
>> + if (!cmdmode && !create_tag_object) {
>> + if (argc == 0)
>> + cmdmode = 'l';
>> + else if (filter.with_commit || filter.points_at.nr || filter.merge_commit)
>> + cmdmode = 'l';
>> + }
>
> Makes sense.
>
>> @@ -483,15 +487,16 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
>> if (column_active(colopts))
>> stop_column_filter();
>> return ret;
>> + } else {
>> + if (filter.lines != -1)
>> + die(_("-n option is only allowed in list mode."));
>> + if (filter.with_commit)
>> + die(_("--contains option is only allowed in list mode."));
>> + if (filter.points_at.nr)
>> + die(_("--points-at option is only allowed in list mode."));
>> + if (filter.merge_commit)
>> + die(_("--merged and --no-merged options are only allowed in list mode."));
>> }
>> - if (filter.lines != -1)
>> - die(_("-n option is only allowed with -l."));
>> - if (filter.with_commit)
>> - die(_("--contains option is only allowed with -l."));
>> - if (filter.points_at.nr)
>> - die(_("--points-at option is only allowed with -l."));
>> - if (filter.merge_commit)
>> - die(_("--merged and --no-merged option are only allowed with -l"));
>
> I'm not sure why these go into the "else" clause here. The other side of
> the conditional (i.e., when we are in list mode) always returns. I don't
> _mind_ it, it's just surprising in this patch.Changed it. It was a wart left over from an earlier version of this that didn't make it on-list where the else mattered.
> While we are re-wording the messages, we may want to drop the periods at > the end of the first three (or keep it on the fourth one, but I our > usual style is to omit it).
Done.
Show 6 quoted lines
>> --- a/t/t7004-tag.sh >> +++ b/t/t7004-tag.sh > > The tests looked reasonable to me. > > -Peff