Quoting Junio C Hamano <gits...@pobox.com>:
SZEDER Gábor <sze...@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 <sze...@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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
