From: SZEDER Gábor <szeder@ira.uka.de>
Date: Fri, 21 Aug 2015 11:40:39 GMT
Subject: Re: [PATCH] describe: make '--always' fallback work after '--exact-match' failed
Message-ID: <20150821134039.Horde.wW7OPRQO28gZidreZRgP7g2@webmail.informatik.kit.edu>
In-Reply-To: <xmqqegix7qjk.fsf@gitster.dls.corp.google.com>


Quoting Junio C Hamano <gitster@pobox.com>:

> SZEDER Gábor <szeder@ira.uka.de> writes:
>
>> 'git describe [...] --always' should always show the unique abbreviated
>> object name as a fallback when the given commit cannot be described with
>> the given set of options, see da2478dbb0 (describe --always: fall back
>> to showing an abbreviated object name, 2008-03-02).
>>
>> However, this is not the case when the combination '--exact-match
>> --always' is given and the commit cannot be described, because in such
>> cases 'git describe' errors out, as if '--always' were not given at all.
>>
>> Respect '--always' and print the unique abbreviated object name instead
>> of erroring out when the commit cannot be described with '--exact-match
>> --always'.
>>
>> Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
>
> Well, that can be argued both ways.  Your patch introduces a
> regression, as "--exact-match" is an instruction to error out when
> no tag exactly matches, and you deliberately break that.

This patch doesn't break '--exact-match', in fact doesn't modify it at all
when it's on its own or combined with other options, but it makes
'--exact-match --always' finally work.

'git describe' errors out by default if it can't describe the given
commit.  So if a user wants an exact match or an error otherwise, then he
should not give '--always' at all, because that's the instruction to not
error out but give the abbreviated object name instead.

Why should '--exact-match' be any different from the other options that
tell 'git describe' what to use for the description?  Why should
'--always' not work with '--exact-match', when it works in the other
cases?

Consider '--contains': it should find a tag that comes after the given
commit or error out if such a tag doesn't exist.  Now, in current git.git:

   $ git describe --contains master
   fatal: cannot describe 'ff86faf2fa02bc21933c9e1dcc75c8d81b3e104a'
   $ git describe --contains --always master
   ff86faf2fa

Or the default behavior without any options: it should find a tag
reachable from the given commit or error out, but what if we pass in a
commit before the first tag?  It recommends '--always':

   $ git describe e83c516
   fatal: No tags can describe 'e83c5163316f89bfbde7d9ab23ca2e25604af290'.
   Try --always, or create some tags.
   $ git describe --always e83c516
   e83c516331


> My knee-jerk reaction is that the most sensible way forward is to
> make --exact-match and --always mutually incompatible.

That would be wrong, it's perfectly valid to ask for an exactly matching
tag or, if there is no such tag, the abbreviated object name as a
fallback.