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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Quoting Junio C Hamano <gitster@xxxxxxxxx>:

SZEDER Gábor <szeder@xxxxxxxxxx> 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@xxxxxxxxxx>

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]