On Fri, Dec 06, 2024 at 01:19:36PM +0900, Junio C Hamano wrote:
> My gut reaction is that it is wrong not to give the abbreviated
> object name in this case, but the price to do so shouldn't be to
> change the behaviour when --exact-match was requested the the user.
I think this is where we differ. You call it a price, but to me it is a
bonus. ;)
> Loosening the interaction between the two options, when both were
> given explicitly, may be an improvement, but I think that should be
> treated as a separate topic, with its merit justified independently,
> since the command has been behaving this way from fairly early
> version, possibly the one that had both of the options for the first
> time.
>
> $ rungit v2.20.0 describe --exact-match HEAD
> fatal: No names found, cannot describe anything.
> $ rungit v2.20.0 describe --exact-match --always HEAD
> fatal: no tag exactly matches '13a3dd7fe014658da465e9621ec3651f5473041e'
> $ rungit v2.20.0 describe --exact-match --candidate=0 HEAD
> fatal: No names found, cannot describe anything.
OK. That's certainly the more conservative approach, since it reduces
the change of behavior from previous versions.
Here's a replacement patch (again, on top of jk/describe-perf).
-- >8 --
Subject: [PATCH] describe: split "found all tags" and max_candidates logic
Commit a30154187a (describe: stop traversing when we run out of names,
2024-10-31) taught git-describe to automatically reduce the
max_candidates setting to match the total number of possible names. This
lets us break out of the traversal rather than fruitlessly searching for
more candidates when there are no more to be found.
However, setting max_candidates to 0 (e.g., if the repo has no tags)
overlaps with the --exact-match option, which explicitly uses the same
value. And this causes a regression with --always, which is ignored in
exact-match mode. We used to get this in a repo with no tags:
$ git describe --always HEAD
b2f0a7f
and now we get:
$ git describe --always HEAD
fatal: no tag exactly matches 'b2f0a7f47f5f2aebe1e7fceff19a57de20a78c06'
The reason is that we bail early in describe_commit() when
max_candidates is set to 0. This logic goes all the way back to
2c33f75754 (Teach git-describe --exact-match to avoid expensive tag
searches, 2008-02-24).
We should obviously fix this regression, but there are two paths,
depending on what you think:
$ git describe --always --exact-match
and
$ git describe --always --candidates=0
should do. Since the "--always" option was added, it has always been
ignored in --exact-match (or --candidates=0) mode. I.e., we treat
--exact-match as a true exact match of a tag, and never fall back to
using --always, even if it was requested.
If we think that's a bug (or at least a misfeature), then the right
solution is to fix it by removing the early bail-out from 2c33f75754,
letting the noop algorithm run and then hitting the --always fallback
output. And then our regression naturally goes away, because it follows
the same path.
If we think that the current "--exact-match --always" behavior is the
right thing, then we have to differentiate the case where we
automatically reduced max_candidates to 0 from the case where the user
asked for it specifically. That's possible to do with a flag, but we can
also just reimplement the logic from a30154187a to explicitly break out
of the traversal when we run out of candidates (rather than relying on
the existing max_candidates check).
My gut feeling is along the lines of option 1 (it's a bug, and people
would be happy for "--exact-match --always" to give the fallback rather
than ignoring "--always"). But the documentation can be interpreted in
the other direction, and we've certainly lived with the existing
behavior for many years. So it's possible that changing it now is the
wrong thing.
So this patch fixes the regression by taking the second option,
retaining the "--exact-match" behavior as-is. There are two new tests.
The first shows that the regression is fixed (we don't even need a new
repo without tags; a restrictive --match is enough to create the
situation that there are no candidate names).
The second test confirms that the "--exact-match --always" behavior
remains unchanged and continues to die when there is no tag pointing at
the specified commit. It's possible we may reconsider this in the
future, but this shows that the approach described above is implemented
faithfully.
We can also run the perf tests in p6100 to see that we've retained the
speedup that a30154187a was going for:
Test HEAD^ HEAD
--------------------------------------------------------------------------------------
6100.2: describe HEAD 0.72(0.64+0.07) 0.72(0.66+0.06) +0.0%
6100.3: describe HEAD with one max candidate 0.01(0.00+0.00) 0.01(0.00+0.00) +0.0%
6100.4: describe HEAD with one tag 0.01(0.01+0.00) 0.01(0.01+0.00) +0.0%
Reported-by: Josh Steadmon <steadmon@xxxxxxxxxx>
Signed-off-by: Jeff King <peff@xxxxxxxx>
---
builtin/describe.c | 5 ++---
t/t6120-describe.sh | 10 ++++++++++
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/builtin/describe.c b/builtin/describe.c
index 8ec3be87df..a6ef8af32a 100644
--- a/builtin/describe.c
+++ b/builtin/describe.c
@@ -367,7 +367,8 @@ static void describe_commit(struct object_id *oid, struct strbuf *dst)
seen_commits++;
- if (match_cnt == max_candidates) {
+ if (match_cnt == max_candidates ||
+ match_cnt == hashmap_get_size(&names)) {
gave_up_on = c;
break;
}
@@ -667,8 +668,6 @@ int cmd_describe(int argc,
NULL);
if (!hashmap_get_size(&names) && !always)
die(_("No names found, cannot describe anything."));
- if (hashmap_get_size(&names) < max_candidates)
- max_candidates = hashmap_get_size(&names);
if (argc == 0) {
if (broken) {
diff --git a/t/t6120-describe.sh b/t/t6120-describe.sh
index 5633b11d01..3f6160d702 100755
--- a/t/t6120-describe.sh
+++ b/t/t6120-describe.sh
@@ -715,4 +715,14 @@ test_expect_success 'describe --broken --dirty with a file with changed stat' '
)
'
+test_expect_success '--always with no refs falls back to commit hash' '
+ git rev-parse HEAD >expect &&
+ git describe --no-abbrev --always --match=no-such-tag >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success '--exact-match does not show --always fallback' '
+ test_must_fail git describe --exact-match --always
+'
+
test_done
--
2.47.1.734.g721956425b
