All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "René Scharfe" <l.s.r@web.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 4/4] worktree add: let worktree_basename() return string copy
Date: Tue, 25 Aug 2026 13:04:58 -0700	[thread overview]
Message-ID: <xmqqld9uklud.fsf@gitster.g> (raw)
In-Reply-To: <20260825180350.2099-5-l.s.r@web.de> ("René Scharfe"'s message of "Tue, 25 Aug 2026 20:03:50 +0200")

René Scharfe <l.s.r@web.de> writes:

> worktree_basename() requires callers to do pointer arithmetic to get the
> actual basename.  Simplify them by doing the calculations in the
> function and returning a copy of the basename directly.

OK.

> Remind programmers to free the result by renaming the function to
> worktree_basename_dup().  Two already do; convert the remaining one from

This is a bit surprising, depending on what "do" refers to, as I
read it to mean "Two callers already free what is returned by the
worktree_basename() function", which cannot be the case (or they
would be segfaulting already).  So I must have misunderstood this
sentence.  I count three callers of the function, so two do
something while the other one that needs conversion does something
else.

> resetting a shared strbuf to freeing the allocated string, which
> requires the same number of lines, but no arithmetic.  The added
> allocation is negligible because it's small and there's only one per run
> of "git worktree add".

This talks about the caller in builtin/worktree.c:add_worktree(),
and it is indeed far easier to read with this patch applied, as
there is no need to copy out only the basename part, and we no
longer need to worry about chomping trailing directory separators.

> @@ -766,10 +765,8 @@ static int dwim_orphan(const struct add_opts *opts, int opt_track, int remote)
>  
>  static char *dwim_branch(const char *path, char **new_branch)
>  {
> -	int n;
>  	int branch_exists;
> -	const char *s = worktree_basename(path, &n);
> -	char *branchname = xmemdupz(s, path + n - s);
> +	char *branchname = worktree_basename_dup(path);
>  	struct strbuf ref = STRBUF_INIT;

Ah, OK, so this is what you mean by "two already do".  Not "two
already free the result", but "two already make a copy before doing
anything else anyway, so why not make worktree_basename_dup() give
them their own copies?".  Makes sense.

> @@ -876,9 +873,7 @@ static int add(int ac, const char **av, const char *prefix,
>  	}
>  
>  	if (opts.orphan && !new_branch) {
> -		int n;
> -		const char *s = worktree_basename(path, &n);
> -		new_branch = new_branch_to_free = xmemdupz(s, path + n - s);
> +		new_branch = new_branch_to_free = worktree_basename_dup(path);

Likewise.


So going back to the confusing part of the log message,

    Remind ... to worktree_basename_dup().  Among the three callers
    of worktree_basename(), two immediately make copies of the
    returned string before using and freeing it, which makes for an
    easy conversion.  Convert the other one from resetting ...

or something like that, perhaps?

Thanks.

  reply	other threads:[~2026-08-25 20:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-25 18:03 [PATCH 0/4] worktree add: worktree_basename() fixes René Scharfe
2026-08-25 18:03 ` [PATCH 1/4] worktree add: don't read out of bounds in worktree_basename() René Scharfe
2026-08-25 18:03 ` [PATCH 2/4] worktree add: reject separator-only path René Scharfe
2026-08-25 18:03 ` [PATCH 3/4] worktree add: trim slashes when deriving branch name from path René Scharfe
2026-08-25 19:47   ` Junio C Hamano
2026-08-25 18:03 ` [PATCH 4/4] worktree add: let worktree_basename() return string copy René Scharfe
2026-08-25 20:04   ` Junio C Hamano [this message]
2026-08-26  4:37     ` René Scharfe
2026-08-26 14:35       ` Junio C Hamano
2026-08-31 18:56         ` 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=xmqqld9uklud.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=l.s.r@web.de \
    /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.