git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jacob Keller <jacob.keller@gmail.com>
Cc: Jacob Keller <jacob.e.keller@intel.com>,
	Git mailing list <git@vger.kernel.org>,
	Johannes Sixt <j6t@kdbg.org>,
	Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH v3 2/5] name-rev: extend --refs to accept multiple patterns
Date: Wed, 18 Jan 2017 14:42:29 -0800	[thread overview]
Message-ID: <xmqqpojk2dnu.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CA+P7+xpMAVq8K41cDZy5FTiRTHoWWd3yOSmLoj4ucAvCPoNa0g@mail.gmail.com> (Jacob Keller's message of "Wed, 18 Jan 2017 13:12:37 -0800")

Jacob Keller <jacob.keller@gmail.com> writes:

> On Wed, Jan 18, 2017 at 12:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
>> 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).
>
> I'm not sure which reasoning makes most sense. Any other opinions?

FWIW, I do think that the design decision to declare that it can be
abbreviated if the ref matches at least one short pattern makes
sense, and I am guessing (because you didn't answer when asked what
_your_ reasoning behind the code was) that you are in agreement.  I
just want it to be spelled out probably as in-code comment, so that
people who later come to this part of the code know why it was
designed that way.  And they can disagree and change it if the end
result is better---I just want to make sure that they can understand
what they are disagreeing when it happens, as opposed to them
scratching their head saying "we do not know why it was chosen to be
done this way, let's make a random change to make it behave
differently".

  reply	other threads:[~2017-01-18 22:43 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
2017-01-18 21:12     ` Jacob Keller
2017-01-18 22:42       ` Junio C Hamano [this message]
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

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

  git send-email \
    --in-reply-to=xmqqpojk2dnu.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.
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 NNTP newsgroup(s).