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

Re: [PATCH] describe: make '--always' fallback work after '--exact-match' failed

From
Junio C Hamano <gitster@pobox.com>
Date
Aug 21, 2015, 15:55 UTC
Message-ID
<xmqqwpwo7i17.fsf@gitster.dls.corp.google.com>
In-Reply-To
<20150821134039.Horde.wW7OPRQO28gZidreZRgP7g2@webmail.informatik.kit.edu>
SZEDER Gábor <szeder@ira.uka.de> writes:
Show 7 quoted lines
> Quoting Junio C Hamano <gitster@pobox.com>:
>
>> Well, that can be argued both ways.
> ...
>
> 'git describe' errors out by default if it can't describe the given
> commit.

Yes. "describe" always fails when it cannot produce an acceptable description.

And "--always" and "--exact-match" are two incompatible ways for users to change what is considered an acceptable description.

 - With "--exact-match" and "--always", the definition of
   "acceptable" changes: by default, only a name based on some
   anchor point is acceptable.
   - "--always" loosens the definition and also allows an
     abbreviated commit object name as acceptable.
   - "--exact-match" tightens the definition.  In addition to "only
     a name based on some anchor point is acceptable", it requires
     that "based on" to be "0 distance from the anchor point".  The
     help text says succinctly: "*ONLY* output exact matches".

If you allow a request with "--exact-match" to show something that is not an exact match, that no longer is "--exact-match". Allowing to mix "--always" to that option breaks it, as what the command does no longer is to "only outputs exact matches".

 - One option "--exact-match" says that it is wrong to show anything
   but exact matches.
 - The other option "--always" says it is willing to show a name
   that is not an exact match.  

These are competing goals. You give preference to the latter, but that is not the only valid point of view.

And that is why I said it can be argued both ways. I think these two are fundamentally incompatible.

[Footnote]
*1* Other parts of "'describe' only considers a name based on some
    anchor point as acceptable." are also modified by various
    options:
    - With "--contains", the definition of "based on" changes
      direction: a commit may be described as somewhere ahead of an
      anchor point by default, but can be described as somewhere behind
      of an anchor point.
    - With "--all" and "--tags", the definition of "anchor point"
      changes: by default, only annotated tags are possible anchor
      points.
Previous: SZEDER GáborNext: SZEDER Gábor
Message 4 of 9 in “describe: make '--always' fallback work after '--exact-match' failed”
  1. describe: make '--always' fallback work after '--exact-match' failedSZEDER Gábor, Aug 20, 2015
  2. Junio C HamanoAug 20, 2015
  3. SZEDER GáborAug 21, 2015
  4. Junio C HamanoAug 21, 2015
  5. describe --contains: default to HEAD when no commit-ish is givenSZEDER Gábor, Aug 21, 2015
  6. Junio C HamanoAug 21, 2015
  7. SZEDER GáborAug 24, 2015
  8. describe --contains: default to HEAD when no commit-ish is givenSZEDER Gábor, Aug 24, 2015
  9. Junio C HamanoAug 24, 2015

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.