git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jacob Keller <jacob.keller@gmail.com>
To: Johannes Sixt <j6t@kdbg.org>
Cc: Jacob Keller <jacob.e.keller@intel.com>,
	Git mailing list <git@vger.kernel.org>
Subject: Re: [PATCH 5/5] describe: teach describe negative pattern matches
Date: Thu, 12 Jan 2017 16:59:46 -0800	[thread overview]
Message-ID: <CA+P7+xrmAmCPOzuaKcm+WxceXnowkM4gKz05tSpdC=CDwpCEug@mail.gmail.com> (raw)
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:
> 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
>

  reply	other threads:[~2017-01-13  1:00 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-12  0:17 [PATCH 0/5] extend git-describe pattern matching Jacob Keller
2017-01-12  0:17 ` [PATCH 1/5] doc: add documentation for OPT_STRING_LIST Jacob Keller
2017-01-12  9:47   ` Johannes Schindelin
2017-01-13  0:51     ` Jacob Keller
2017-01-12  0:17 ` [PATCH 2/5] name-rev: extend --refs to accept multiple patterns Jacob Keller
2017-01-12  9:56   ` Johannes Schindelin
2017-01-13  0:56     ` Jacob Keller
2017-01-12  0:17 ` [PATCH 3/5] name-rev: add support to discard refs by pattern match Jacob Keller
2017-01-12  9:57   ` Johannes Schindelin
2017-01-13  0:56     ` Jacob Keller
2017-01-12  0:17 ` [PATCH 4/5] describe: teach --match to accept multiple patterns Jacob Keller
2017-01-12  0:17 ` [PATCH 5/5] describe: teach describe negative pattern matches Jacob Keller
2017-01-12  9:42   ` Johannes Schindelin
2017-01-12 22:02     ` Junio C Hamano
2017-01-12 13:45   ` Johannes Sixt
2017-01-13  0:59     ` Jacob Keller [this message]
2017-01-13  6:43       ` Johannes Sixt
2017-01-13  6:57         ` Jacob Keller
2017-01-13 21:31           ` Johannes Sixt
2017-01-17 23:31             ` Jacob Keller
2017-01-18 12:44               ` Johannes Schindelin
2017-01-18 21:04                 ` Jacob Keller
2017-01-12 10:05 ` [PATCH 0/5] extend git-describe pattern matching Johannes Schindelin
2017-01-13 18:48 ` Junio C Hamano
2017-01-13 20:41   ` Jacob Keller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+P7+xrmAmCPOzuaKcm+WxceXnowkM4gKz05tSpdC=CDwpCEug@mail.gmail.com' \
    --to=jacob.keller@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=j6t@kdbg.org \
    --cc=jacob.e.keller@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).