git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v3 2/5] name-rev: extend --refs to accept multiple patterns

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 18, 2017, 22:42 UTC
Message-ID
<xmqqpojk2dnu.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<CA+P7+xpMAVq8K41cDZy5FTiRTHoWWd3yOSmLoj4ucAvCPoNa0g@mail.gmail.com>
Jacob Keller <jacob.keller@gmail.com> writes:
Show 21 quoted lines
> 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".

Previous: Jacob KellerNext: Jacob Keller
Message 13 of 22 in “extend git-describe pattern matching”
  1. 0/5 extend git-describe pattern matchingJacob Keller, Jan 18, 2017
  2. 4/5 describe: teach --match to accept multiple patternsJacob Keller, Jan 18, 2017
  3. 5/5 describe: teach describe negative pattern matchesJacob Keller, Jan 18, 2017
  4. Junio C HamanoJan 18, 2017
  5. 3/5 name-rev: add support to exclude refs by pattern matchJacob Keller, Jan 18, 2017
  6. Junio C HamanoJan 18, 2017
  7. Jacob KellerJan 18, 2017
  8. Junio C HamanoJan 18, 2017
  9. Jacob KellerJan 18, 2017
  10. 2/5 name-rev: extend --refs to accept multiple patternsJacob Keller, Jan 18, 2017
  11. Junio C HamanoJan 18, 2017
  12. Jacob KellerJan 18, 2017
  13. Junio C HamanoJan 18, 2017
  14. 1/5 doc: add documentation for OPT_STRING_LISTJacob Keller, Jan 18, 2017
  15. Junio C HamanoJan 18, 2017
  16. Philip OakleyJan 18, 2017
  17. Junio C HamanoJan 18, 2017
  18. Johannes SchindelinJan 19, 2017
  19. Jacob KellerJan 18, 2017
  20. Junio C HamanoJan 19, 2017
  21. Junio C HamanoJan 18, 2017
  22. Jacob KellerJan 18, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.