From: shejialuo <shejialuo@gmail.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
Patrick Steinhardt <ps@pks.im>
Subject: Re: [PATCH v2 2/8] string-list: remove unused "insert_at" parameter from add_entry
Date: Mon, 26 May 2025 22:01:57 +0800 [thread overview]
Message-ID: <aDR0VS_4n8Io0QYp@ArchLinux> (raw)
In-Reply-To: <20250519075119.GE102701@coredump.intra.peff.net>
On Mon, May 19, 2025 at 03:51:19AM -0400, Jeff King wrote:
> On Sun, May 18, 2025 at 11:57:07PM +0800, shejialuo wrote:
>
> > In "add_entry", we accept "insert_at" parameter which must be either -1
> > (auto) or between 0 and `list->nr` inclusive. Any other value is
> > invalid. When caller specify any invalid "insert_at" value, we won't
> > check the range and move the element, which would definitely cause the
> > trouble.
> >
> > However, we only use "add_entry" in "string_list_insert" function and we
> > always pass the "-1" for "insert_at" parameter. So, we never use this
> > parameter to insert element in a user specified position. Let's delete
> > this parameter. If there is any requirement later, we need to use a
> > better way to do this.
>
> We can see from looking at the code that removing this will not change
> the behavior. But that always makes me wonder why it was there in the
> first place, and whether we might ever want it.
>
Yes, I agree. Actually, in my first implementation, I didn't realise
that this is redundant. However, when inspecting the code carefully, I
find out this is useless.
> The answer in this case is that we used to have another function,
> string_list_insert_at_index(), which used the extra insert_at parameter.
> The idea being that you could call string_list_find_insert_index(),
> decide whether there was something already there, and then insert
> without repeating the binary search.
>
> But you can see in callers like 63226218ba (mailmap: use higher level
> string list functions, 2014-11-24) that this was not really that useful
> (in that commit we just try to insert and check the util pointer to see
> if we need to add the auxiliary structure).
>
> So the function went away in f8c4ab611a (string_list: remove
> string_list_insert_at_index() from its API, 2014-11-24), and I suspect
> we won't need it again. (Also, I think these days we'd probably use a
> strmap instead anyway).
>
Thanks for the hint. By seeing this commit, I totally understand the
history. Because we delete `string_list_insert_at_index`, we simply call
"add_entry" by specifying "auto" mode and somehow we don't delete the
legacy check in "add_entry".
But I have one question: should I include the information in the commit
message? I feel doing this would be chaty. But I somehow think we should
do this.
Thanks,
Jialuo
next prev parent reply other threads:[~2025-05-26 14:01 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-22 14:53 [PATCH 0/5] enhance "string_list" code and test shejialuo
2025-04-22 14:54 ` [PATCH 1/5] string-list: fix sign compare warnings shejialuo
2025-04-22 21:02 ` Junio C Hamano
2025-04-24 12:27 ` shejialuo
2025-04-22 14:54 ` [PATCH 2/5] u-string-list: move "test_split" into "u-string-list.c" shejialuo
2025-04-22 21:27 ` Junio C Hamano
2025-04-24 12:50 ` shejialuo
2025-04-23 11:52 ` Patrick Steinhardt
2025-04-24 12:53 ` shejialuo
2025-04-22 14:55 ` [PATCH 3/5] u-string-list: move "test_split_in_place" to "u-string-list.c" shejialuo
2025-04-23 11:53 ` Patrick Steinhardt
2025-04-22 14:55 ` [PATCH 4/5] u-string-list: move "filter string" test " shejialuo
2025-04-22 14:55 ` [PATCH 5/5] u-string-list: move "remove duplicates" " shejialuo
2025-04-23 11:53 ` Patrick Steinhardt
2025-04-24 12:56 ` shejialuo
2025-05-18 15:55 ` [PATCH v2 0/8] enhance "string_list" code and test shejialuo
2025-05-18 15:56 ` [PATCH v2 1/8] string-list: fix sign compare warnings for loop iterator shejialuo
2025-05-19 7:17 ` Patrick Steinhardt
2025-05-26 13:50 ` shejialuo
2025-05-18 15:57 ` [PATCH v2 2/8] string-list: remove unused "insert_at" parameter from add_entry shejialuo
2025-05-19 7:17 ` Patrick Steinhardt
2025-05-26 13:52 ` shejialuo
2025-05-19 7:51 ` Jeff King
2025-05-26 14:01 ` shejialuo [this message]
2025-05-26 14:21 ` Patrick Steinhardt
2025-05-18 15:57 ` [PATCH v2 3/8] string-list: return index directly when inserting an existing element shejialuo
2025-05-19 7:18 ` Patrick Steinhardt
2025-05-26 14:13 ` shejialuo
2025-05-19 7:58 ` Jeff King
2025-05-26 14:20 ` shejialuo
2025-05-18 15:57 ` [PATCH v2 4/8] string-list: enable sign compare warnings check shejialuo
2025-05-19 7:18 ` Patrick Steinhardt
2025-05-26 14:27 ` shejialuo
2025-05-18 15:57 ` [PATCH v2 5/8] u-string-list: move "test_split" into "u-string-list.c" shejialuo
2025-05-19 7:17 ` Patrick Steinhardt
2025-05-18 15:57 ` [PATCH v2 6/8] u-string-list: move "test_split_in_place" to "u-string-list.c" shejialuo
2025-05-18 15:58 ` [PATCH v2 7/8] u-string-list: move "filter string" test " shejialuo
2025-05-19 7:18 ` Patrick Steinhardt
2025-05-26 14:33 ` shejialuo
2025-05-18 15:58 ` [PATCH v2 8/8] u-string-list: move "remove duplicates" " shejialuo
2025-05-19 7:18 ` Patrick Steinhardt
2025-06-29 4:26 ` [PATCH v3 0/8] enhance "string_list" code and test shejialuo
2025-06-29 4:27 ` [PATCH v3 1/8] string-list: fix sign compare warnings for loop iterator shejialuo
2025-06-29 4:27 ` [PATCH v3 2/8] string-list: remove unused "insert_at" parameter from add_entry shejialuo
2025-06-29 4:27 ` [PATCH v3 3/8] string-list: return index directly when inserting an existing element shejialuo
2025-06-29 4:28 ` [PATCH v3 4/8] string-list: enable sign compare warnings check shejialuo
2025-06-29 4:28 ` [PATCH v3 5/8] u-string-list: move "test_split" into "u-string-list.c" shejialuo
2025-06-29 4:28 ` [PATCH v3 6/8] u-string-list: move "test_split_in_place" to "u-string-list.c" shejialuo
2025-06-29 4:28 ` [PATCH v3 7/8] u-string-list: move "filter string" test " shejialuo
2025-06-29 4:28 ` [PATCH v3 8/8] u-string-list: move "remove duplicates" " shejialuo
2025-07-04 5:24 ` [PATCH v3 0/8] enhance "string_list" code and test Patrick Steinhardt
2025-07-07 15:10 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aDR0VS_4n8Io0QYp@ArchLinux \
--to=shejialuo@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=ps@pks.im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.