[PATCH 2/2] prefix_ref_iterator_advance(): relax the check of trim length
- From
Michael Haggerty <mhagger@alum.mit.edu>
- Date
- Jun 14, 2017, 09:07 UTC
- Message-ID
- <0c63f38bf922f285d6d62fc9cbbc3f5b756e75bf.1497430232.git.mhagger@alum.mit.edu>
- In-Reply-To
- <cover.1497430232.git.mhagger@alum.mit.edu>
Before the previous commit, `for_each_bad_bisect_ref()` called `for_each_fullref_in_submodule()` in such a way as to trim the whole refname away. This is a questionable use of the API, but is not ipso facto dangerous, so tolerate it in case there are other callers relying on this behavior. But continue to refuse to trim *more* characters than the refname contains, as that really makes no sense.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> --- refs/iterator.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/refs/iterator.c b/refs/iterator.c index 4cf449ef66..de52d5fe93 100644 --- a/refs/iterator.c +++ b/refs/iterator.c @@ -298,11 +298,11 @@ static int prefix_ref_iterator_advance(struct ref_iterator *ref_iterator) * you haven't already checked for via a * prefix check, whether via this * `prefix_ref_iterator` or upstream in - * `iter0`). So if there wouldn't be at least - * one character left in the refname after - * trimming, report it as a bug: + * `iter0`. So consider it a bug if we are + * asked to trim off more characters than the + * refname contains: */ - if (strlen(iter->iter0->refname) <= iter->trim) + if (strlen(iter->iter0->refname) < iter->trim) die("BUG: attempt to trim too many characters"); iter->base.refname = iter->iter0->refname + iter->trim; } else {
-- 2.11.0