git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Caleb White <cdwhite3@pm.me>
Cc: shejialuo <shejialuo@gmail.com>,  git@vger.kernel.org
Subject: Re: [PATCH v3 1/3] worktree: refactor infer_backlink() to use *strbuf
Date: Thu, 10 Oct 2024 12:14:55 -0700	[thread overview]
Message-ID: <xmqqmsjbkbww.fsf@gitster.g> (raw)
In-Reply-To: <e1RptKNShhPZHXDhBkQBaCNCmKBKik4nQzRShqtgVfjcH7vBWpuLYV60PSHaJ0diX-oG3XiKHc7IebhIZM4eSkeYdQQZ_QYK2ixxsK-XwrE=@pm.me> (Caleb White's message of "Thu, 10 Oct 2024 16:41:03 +0000")

Caleb White <cdwhite3@pm.me> writes:

>> Question here: should we use `strbuf_reset` here? I want to know the
>> reason why you design this. Is the caller's responsibility to clear the
>> "inferred" when calling this function?
>
> Yes we should, sure it is the caller's responsibility but this just helps
> prevent bugs. There's plenty of functions that reset the strbuf that's
> passed to the function before modifying it.

If the API says that it _appends_ what it found in the supplied
strbuf, then it is the caller's responsibility to ensure that the
strbuf being passed is empty, if the caller wants the resulting
strbuf to hold only what the function found.

If the API says it _returns_ what it found in the supplied strbuf,
then the function is responsible to discard what the supplied strbuf
originally has.

As an API design, if it is rarely useful for callers to be able to
append, then the latter is simpler to use, but there are many cases
where the "append" semantics is useful (see strbuf.c to find
examples).

In this particular case, it is rarely useful for the caller to get
the result appended to a string it already has before calling this
function, so unconditionally discarding what the caller had, without
telling the caller that it is responsible for passing an empty buffer,
is the right thing, I wuld think.

Thanks.

  parent reply	other threads:[~2024-10-10 19:14 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-08  3:12 [PATCH v3 0/3] Link worktrees with relative paths Caleb White via B4 Relay
2024-10-08  3:12 ` [PATCH v3 1/3] worktree: refactor infer_backlink() to use *strbuf Caleb White via B4 Relay
2024-10-10 15:52   ` shejialuo
2024-10-10 16:41     ` Caleb White
2024-10-10 17:26       ` shejialuo
2024-10-10 17:52         ` Caleb White
2024-10-10 20:03           ` Junio C Hamano
2024-10-10 20:24             ` Caleb White
2024-10-10 19:14       ` Junio C Hamano [this message]
2024-10-08  3:12 ` [PATCH v3 2/3] worktree: link worktrees with relative paths Caleb White via B4 Relay
2024-10-08 23:09   ` Junio C Hamano
2024-10-09 18:34     ` Caleb White
2024-10-09 19:10       ` Junio C Hamano
2024-10-09 19:19         ` Caleb White
2024-10-09 23:37           ` Junio C Hamano
2024-10-10 17:30             ` Caleb White
2024-10-11  4:03             ` Caleb White
2024-10-22  4:32             ` Caleb White
2024-10-09 10:11   ` Phillip Wood
2024-10-09 18:49     ` Caleb White
2024-10-08  3:12 ` [PATCH v3 3/3] worktree: add test for path handling in linked worktrees Caleb White via B4 Relay
2024-10-08  4:48 ` [PATCH v3 0/3] Link worktrees with relative paths Caleb White
2024-10-08 19:00 ` Junio C Hamano
2024-10-08 21:55   ` Caleb White

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=xmqqmsjbkbww.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=cdwhite3@pm.me \
    --cc=git@vger.kernel.org \
    --cc=shejialuo@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 NNTP newsgroup(s).