Re: [PATCH v4 00/18] Extending the shelf-life of "git describe" output
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jul 3, 2012, 18:20 UTC
- Message-ID
- <7v3958wvtx.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20120703071940.GB16679@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> However, if you feed a partial sha1 for which there are > multiple matches, none of which satisfy the disambiguation hint, then we > used to say "short SHA1 is ambiguous", and now we don't.
In finish_object_disambiguation(), if the candidate hasn't been checked, there are two cases:
- It is the first and only object that match the prefix; or - It replaced another object that matched the prefix but that object did not satisfy ds->fn() callback.
And the former case we set ds->candidate_ok to true without doing anything else, while for the latter we check the candidate, which may set ds->candidate_ok to false.
At this point in the code, ds->candidate_ok can be false only if this last-round check found that the candidate does not pass the check, because the state after update_candidates() returns cannot satisfy
!ds->ambiguous && ds->candidate_exists && ds->candidate_checked
and !ds->canidate_ok at the same time.
Hence, when we execute this "return", we know we have seen more than one object that match the prefix (and none of them satisfied ds->fn), meaning that we should say "the short name is ambiguous", not "there is no object that matches the prefix".
Please sanity check; I think it is just this one-liner, but I am having hard time convincing myself that it can be that simple.
sha1_name.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sha1_name.c b/sha1_name.c index 2e2dbb8..c824bdd 100644 --- a/sha1_name.c +++ b/sha1_name.c @@ -212,7 +212,7 @@ static int finish_object_disambiguation(struct disambiguate_state *ds, ds->fn(ds->candidate, ds->cb_data)); if (!ds->candidate_ok) - return SHORT_NAME_NOT_FOUND; + return SHORT_NAME_AMBIGUOUS; hashcpy(sha1, ds->candidate); return 0;