git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jacob Keller <jacob.e.keller@intel.com>
Cc: git@vger.kernel.org, Johannes Sixt <j6t@kdbg.org>,
	Johannes Schindelin <johannes.schindelin@gmx.de>,
	Jacob Keller <jacob.keller@gmail.com>
Subject: Re: [PATCH v3 2/5] name-rev: extend --refs to accept multiple patterns
Date: Wed, 18 Jan 2017 12:04:43 -0800	[thread overview]
Message-ID: <xmqqy3y8878k.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20170118000930.5431-3-jacob.e.keller@intel.com> (Jacob Keller's message of "Tue, 17 Jan 2017 16:09:27 -0800")

Jacob Keller <jacob.e.keller@intel.com> writes:

> From: Jacob Keller <jacob.keller@gmail.com>
>
> Teach git name-rev to take a string list of patterns from --refs instead
> of only a single pattern. The list of patterns will be matched
> inclusively, such that a ref only needs to match one pattern to be
> included. If a ref will only be excluded if it does not match any of the
> patterns.

I think "If a" in the last sentence should be "A".

>  --refs=<pattern>::
>  	Only use refs whose names match a given shell pattern.  The pattern
> -	can be one of branch name, tag name or fully qualified ref name.
> +	can be one of branch name, tag name or fully qualified ref name. If
> +	given multiple times, use refs whose names match any of the given shell
> +	patterns. Use `--no-refs` to clear any previous ref patterns given.

Unlike 1/5, this is facing the end-users, and the last sentence is
very appropriate.

> +	if (data->ref_filters.nr) {
> +		struct string_list_item *item;
> +		int matched = 0;
> +
> +		/* See if any of the patterns match. */
> +		for_each_string_list_item(item, &data->ref_filters) {
> +			/*
> +			 * We want to check every pattern even if we already
> +			 * found a match, just in case one of the later
> +			 * patterns could abbreviate the output.
> +			 */
> +			switch (subpath_matches(path, item->string)) {
> +			case -1: /* did not match */
> +				break;
> +			case 0: /* matched fully */
> +				matched = 1;
> +				break;
> +			default: /* matched subpath */
> +				matched = 1;
> +				can_abbreviate_output = 1;
> +				break;
> +			}
>  		}

I agree that we cannot short-cut on the first match to make sure
that the outcome is stable, but I wondered what should be shown when
we do have multiple matches.  Say I gave

    --refs="v*" --refs="refs/tags/v1.*"

and refs/tags/v1.0 matched.  The above code would say we can
abbreviate.

What is the reason behind this design decision?  Is it because it is
clear that the user shows her willingness to accept more compact
form by having --refs="v*" that would allow shortening?  If that is
the case, I think I agree with the reasoning.  But we probably want
to write it down somewhere, because another reasoning, which may
also be valid, would call for an opposite behaviour (i.e. the more
specific --refs="refs/tags/v1.*" also matched, so let's show that
fact by not shortening).


  reply	other threads:[~2017-01-18 20:04 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-18  0:09 [PATCH v3 0/5] extend git-describe pattern matching Jacob Keller
2017-01-18  0:09 ` [PATCH v3 1/5] doc: add documentation for OPT_STRING_LIST Jacob Keller
2017-01-18 19:45   ` Junio C Hamano
2017-01-18 20:08     ` Philip Oakley
2017-01-18 20:58       ` Junio C Hamano
2017-01-19 16:55         ` Johannes Schindelin
2017-01-18 21:10     ` Jacob Keller
2017-01-19 17:58       ` Junio C Hamano
2017-01-18  0:09 ` [PATCH v3 2/5] name-rev: extend --refs to accept multiple patterns Jacob Keller
2017-01-18 20:04   ` Junio C Hamano [this message]
2017-01-18 21:12     ` Jacob Keller
2017-01-18 22:42       ` Junio C Hamano
2017-01-18  0:09 ` [PATCH v3 3/5] name-rev: add support to exclude refs by pattern match Jacob Keller
2017-01-18 20:11   ` Junio C Hamano
2017-01-18 21:13     ` Jacob Keller
2017-01-18 21:56       ` Junio C Hamano
2017-01-18 22:31         ` Jacob Keller
2017-01-18  0:09 ` [PATCH v3 4/5] describe: teach --match to accept multiple patterns Jacob Keller
2017-01-18  0:09 ` [PATCH v3 5/5] describe: teach describe negative pattern matches Jacob Keller
2017-01-18 20:17   ` Junio C Hamano
2017-01-18 20:18 ` [PATCH v3 0/5] extend git-describe pattern matching Junio C Hamano
2017-01-18 21:06   ` 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=xmqqy3y8878k.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=j6t@kdbg.org \
    --cc=jacob.e.keller@intel.com \
    --cc=jacob.keller@gmail.com \
    --cc=johannes.schindelin@gmx.de \
    /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).