Re: [PATCH 3/7] reftable/refname: refactor binary search over refnames
- From
Justin Tobler <jltobler@gmail.com>
- Date
- Mar 22, 2024, 18:55 UTC
- Message-ID
- <4ea7gnm5gbuvqnoyxdll3ccxxhr4bmlgzwpjtc7kqzbaf5juzb@5kwcy2qhblss>
- In-Reply-To
- <44386818ce681da02f00a498acf66043aa55558e.1711109214.git.ps@pks.im>
On 24/03/22 01:22PM, Patrick Steinhardt wrote:
Show 25 quoted lines
> It is comparatively hard to understand how exactly the binary search
> over refnames works given that the function and variable names are not
> exactly easy to grasp. Rename them to make this more obvious. This
> should not result in any change in behaviour.
>
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
> reftable/refname.c | 44 ++++++++++++++++++++++----------------------
> 1 file changed, 22 insertions(+), 22 deletions(-)
>
> diff --git a/reftable/refname.c b/reftable/refname.c
> index 64eba1b886..9ec488d727 100644
> --- a/reftable/refname.c
> +++ b/reftable/refname.c
> @@ -12,15 +12,15 @@
> #include "refname.h"
> #include "reftable-iterator.h"
>
> -struct find_arg {
> - char **names;
> - const char *want;
> +struct refname_needle_lesseq_args {
> + char **haystack;
> + const char *needle;
> };I agree that the previous `names` and `want` are a bit ambiguous. What do you think about `refnames` and `target_refname` instead?
-Justin