Re: [PATCH 5/5] describe: teach describe negative pattern matches

From: Jacob Keller <jacob.keller@gmail.com>
Date: Jan 13, 2017, 00:59 UTC
Message-ID: <CA+P7+xrmAmCPOzuaKcm+WxceXnowkM4gKz05tSpdC=CDwpCEug@mail.gmail.com>
In-Reply-To: <5f723a0d-623f-bf97-00de-29d430484fed@kdbg.org>

On Thu, Jan 12, 2017 at 5:45 AM, Johannes Sixt <j6t@kdbg.org> wrote:

Show 32 quoted lines

> Am 12.01.2017 um 01:17 schrieb Jacob Keller:
>>
>> From: Jacob Keller <jacob.keller@gmail.com>
>>
>> Teach git-describe the `--discard` option which will allow specifying
>> a glob pattern of tags to ignore. This can be combined with the
>> `--match` patterns to enable more flexibility in determining which tags
>> to consider.
>>
>> For example, suppose you wish to find the first official release tag
>> that contains a certain commit. If we assume that official release tags
>> are of the form "v*" and pre-release candidates include "*rc*" in their
>> name, we can now find the first tag that introduces commit abcdef via:
>>
>>   git describe --contains --match="v*" --discard="*rc*"
>
>
> I have a few dozen topic branches, many of them are work in progress and
> named wip/something. To see the completed branches, I routinely say
>
>     gitk --exclude=wip/* --branches
>
> these days.
>
> It would be great if you could provide the same user interface here. The
> example in the commit message would then look like this:
>
>    git describe --contains --exclude="*rc*" --match="v*"
>
> (I'm not saying that you should add --branches, but that you should prefer
> --exclude over --discard. Also, the order of --exclude and --match would be
> important.)

I think that --exclude makes sense, but the current implementation does not differentiate ordering, since both are merely accumulated into string_lists and then matched together. I'm not sure how order would impact things here? In the current implementation, if something is excluded and matched, it will be excluded. That is, exclusion patterns take precedence over match patterns. I think this makes the most sense semantically.

Thanks, Jake

>
> -- Hannes
>