From: Calvin Wan <calvinwan@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, newren@gmail.com
Subject: Re: [PATCH 0/6] strbuf cleanups
Date: Tue, 2 May 2023 15:36:13 -0700 [thread overview]
Message-ID: <CAFySSZCz=ydmOZ+580Xhpp93NJbqyL21pPU=wfme_-zj6m8agw@mail.gmail.com> (raw)
In-Reply-To: <xmqqttwuxtnz.fsf@gitster.g>
On Tue, May 2, 2023 at 3:20 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Calvin Wan <calvinwan@google.com> writes:
>
> > Strbuf is a basic structure that should function as a low-level library
> > due to how generic it is. Over time certain functions inside of
> > strbuf.[ch] have been added with dependencies to higher level objects
> > and functions. This series cleans up some of those higher level
> > dependencies by moving the offending functions to the files they
> > interact with. With the goal of eventually being able to stand up strbuf
> > as a libary, this series also removes the use of environment variables
> > from strbuf.
>
> I touched a bit of the same in my review for 1/6, but the main
> thrust of the series is that you want to make strbuf.[ch] mostly
> about "string processing primitives".
Thanks for clarifying the boundary I was attempting to explain in my
cover letter, but unsuccessfully did so.
>
> Any meaningful features relate to more than one conceptual things,
> e.g. pathname functions work on "paths" (that is one) and it may
> store computed result in a "strbuf" (that is another). We have
> historically called them strbuf_do_something() and gave the pointer
> to a strbuf that receives the result. And this series wants to
> reverse the course and want to see strbuf that is more pure.
>
> That's fine. The strbuf has become so successful a data structure,
> its use has become as ubiquitous as a plain string or an integer in
> our codebase.
>
> But if we were moving in that direction, I have to wonder if some of
> these functions also need to be renamed to lose their strbuf_
> prefix. A function that takes a pathname and creates a directory
> there is not called string_mkdir() just because it takes a pathname
> as a string. A function that takes a string buffer and a path, and
> reads the symbolic link content is not called string_readlink() just
> because it learns the symlink target in a string buffer. What their
> parameters mean matters a lot more than what type these parameters
> are represented as.
I agree that with the functions that are moved out from strbuf, they
should be refactored in the future to the form, taking absolute path
as an example, strbuf_addstr(sb, get_absolute_path(path)) or something
similar.
>
> With some other topics in flight, merging this to 'seen' and merging
> this to 'next' may require different merge fixes, but I'll manage.
>
> Thanks.
>
next prev parent reply other threads:[~2023-05-02 22:36 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-02 21:14 [PATCH 0/6] strbuf cleanups Calvin Wan
2023-05-02 21:14 ` [PATCH 1/6] abspath: move related functions to abspath Calvin Wan
2023-05-02 21:42 ` Junio C Hamano
2023-05-02 21:14 ` [PATCH 2/6] credential-store: move related functions to credential-store file Calvin Wan
2023-05-02 21:52 ` Junio C Hamano
2023-05-03 16:28 ` Jeff King
2023-05-03 16:34 ` Jeff King
2023-05-03 18:38 ` Calvin Wan
2023-05-02 21:14 ` [PATCH 3/6] object-name: move related functions to object-name Calvin Wan
2023-05-02 21:14 ` [PATCH 4/6] path: move related function to path Calvin Wan
2023-05-02 21:14 ` [PATCH 5/6] strbuf: clarify dependency Calvin Wan
2023-05-03 1:56 ` Elijah Newren
2023-05-02 21:14 ` [PATCH 6/6] strbuf: remove environment variables Calvin Wan
2023-05-03 2:15 ` Elijah Newren
2023-05-02 22:20 ` [PATCH 0/6] strbuf cleanups Junio C Hamano
2023-05-02 22:31 ` Junio C Hamano
2023-05-02 23:51 ` Felipe Contreras
2023-05-02 22:36 ` Calvin Wan [this message]
2023-05-03 2:37 ` Elijah Newren
2023-05-03 18:00 ` Calvin Wan
2023-05-07 0:14 ` Elijah Newren
2023-05-07 13:14 ` Jeff King
2023-05-03 18:48 ` [PATCH v2 0/7] " Calvin Wan
2023-05-03 18:50 ` [PATCH v2 1/7] strbuf: clarify API boundary Calvin Wan
2023-05-03 18:50 ` [PATCH v2 2/7] abspath: move related functions to abspath Calvin Wan
2023-05-03 18:50 ` [PATCH v2 3/7] credential-store: move related functions to credential-store file Calvin Wan
2023-05-03 18:50 ` [PATCH v2 4/7] object-name: move related functions to object-name Calvin Wan
2023-05-03 18:50 ` [PATCH v2 5/7] path: move related function to path Calvin Wan
2023-05-03 18:50 ` [PATCH v2 6/7] strbuf: clarify dependency Calvin Wan
2023-05-03 19:26 ` Junio C Hamano
2023-05-03 18:50 ` [PATCH v2 7/7] strbuf: remove environment variables Calvin Wan
2023-05-03 19:24 ` Junio C Hamano
2023-05-03 19:41 ` Calvin Wan
2023-05-03 19:45 ` Junio C Hamano
2023-05-03 19:42 ` [PATCH v3 7/7] strbuf: remove environment variable Calvin Wan
2023-05-05 22:33 ` [PATCH v2 0/7] strbuf cleanups Junio C Hamano
2023-05-08 16:38 ` Calvin Wan
2023-05-07 0:40 ` Elijah Newren
2023-05-07 21:47 ` Felipe Contreras
2023-05-08 16:57 ` [PATCH v4 " Calvin Wan
2023-05-08 16:59 ` [PATCH v4 1/7] strbuf: clarify API boundary Calvin Wan
2023-05-08 17:22 ` Eric Sunshine
2023-05-10 22:51 ` Junio C Hamano
2023-05-08 16:59 ` [PATCH v4 2/7] abspath: move related functions to abspath Calvin Wan
2023-05-08 16:59 ` [PATCH v4 3/7] credential-store: move related functions to credential-store file Calvin Wan
2023-05-08 16:59 ` [PATCH v4 4/7] object-name: move related functions to object-name Calvin Wan
2023-05-08 16:59 ` [PATCH v4 5/7] path: move related function to path Calvin Wan
2023-05-08 16:59 ` [PATCH v4 6/7] strbuf: clarify dependency Calvin Wan
2023-05-08 16:59 ` [PATCH v4 7/7] strbuf: remove global variable Calvin Wan
2023-05-10 8:12 ` Phillip Wood
2023-05-09 1:57 ` [PATCH v4 0/7] strbuf cleanups Elijah Newren
2023-05-09 2:13 ` Felipe Contreras
2023-05-11 19:44 ` [PATCH v5 " Calvin Wan
2023-05-11 19:48 ` [PATCH v5 1/7] strbuf: clarify API boundary Calvin Wan
2023-05-11 19:57 ` Eric Sunshine
2023-05-11 20:03 ` Calvin Wan
2023-05-11 19:48 ` [PATCH v5 2/7] abspath: move related functions to abspath Calvin Wan
2023-05-11 19:48 ` [PATCH v5 3/7] credential-store: move related functions to credential-store file Calvin Wan
2023-05-11 19:48 ` [PATCH v5 4/7] object-name: move related functions to object-name Calvin Wan
2023-05-11 19:48 ` [PATCH v5 5/7] path: move related function to path Calvin Wan
2023-05-11 19:48 ` [PATCH v5 6/7] strbuf: clarify dependency Calvin Wan
2023-05-11 19:48 ` [PATCH v5 7/7] strbuf: remove global variable Calvin Wan
2023-05-11 20:24 ` Eric Sunshine
2023-05-11 21:42 ` Junio C Hamano
2023-05-12 14:54 ` Phillip Wood
2023-05-12 14:53 ` Phillip Wood
2023-05-12 19:31 ` Junio C Hamano
2023-05-12 17:14 ` [PATCH v6 0/7] strbuf cleanups Calvin Wan
2023-05-12 17:15 ` [PATCH v6 1/7] strbuf: clarify API boundary Calvin Wan
2023-05-12 17:15 ` [PATCH v6 2/7] abspath: move related functions to abspath Calvin Wan
2023-05-12 17:15 ` [PATCH v6 3/7] credential-store: move related functions to credential-store file Calvin Wan
2023-05-12 17:15 ` [PATCH v6 4/7] object-name: move related functions to object-name Calvin Wan
2023-05-12 17:15 ` [PATCH v6 5/7] path: move related function to path Calvin Wan
2023-05-12 17:15 ` [PATCH v6 6/7] strbuf: clarify dependency Calvin Wan
2023-05-12 17:15 ` [PATCH v6 7/7] strbuf: remove global variable Calvin Wan
2023-05-12 20:24 ` [PATCH v6 0/7] strbuf cleanups Junio C Hamano
2023-05-13 5:54 ` Eric Sunshine
2023-06-06 19:47 ` [PATCH v7 " Calvin Wan
2023-06-06 19:48 ` [PATCH v7 1/7] strbuf: clarify API boundary Calvin Wan
2023-06-06 19:48 ` [PATCH v7 2/7] strbuf: clarify dependency Calvin Wan
2023-06-06 19:48 ` [PATCH v7 3/7] abspath: move related functions to abspath Calvin Wan
2023-06-06 19:48 ` [PATCH v7 4/7] credential-store: move related functions to credential-store file Calvin Wan
2023-06-06 19:48 ` [PATCH v7 5/7] object-name: move related functions to object-name Calvin Wan
2023-06-06 19:48 ` [PATCH v7 6/7] path: move related function to path Calvin Wan
2023-06-06 19:48 ` [PATCH v7 7/7] strbuf: remove global variable Calvin Wan
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='CAFySSZCz=ydmOZ+580Xhpp93NJbqyL21pPU=wfme_-zj6m8agw@mail.gmail.com' \
--to=calvinwan@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=newren@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).