git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Mathew George <mathewegeorge@gmail.com>,  git@vger.kernel.org
Subject: Re: [PATCH 03/11] remote: transfer ownership of memory in add_url(), etc
Date: Mon, 17 Jun 2024 10:42:25 -0700	[thread overview]
Message-ID: <xmqqv827a2ke.fsf@gitster.g> (raw)
In-Reply-To: <20240616045937.GB17750@coredump.intra.peff.net> (Jeff King's message of "Sun, 16 Jun 2024 00:59:37 -0400")

Jeff King <peff@peff.net> writes:

> On Fri, Jun 14, 2024 at 10:04:50AM -0700, Junio C Hamano wrote:
>
>> >  static void add_pushurl_alias(struct remote_state *remote_state,
>> > @@ -79,6 +79,7 @@ static void add_pushurl_alias(struct remote_state *remote_state,
>> >  	char *alias = alias_url(url, &remote_state->rewrites_push);
>> >  	if (alias)
>> >  		add_pushurl(remote, alias);
>> > +	free(alias);
>> >  }
>> 
>> OK.  I wondered if we want to strdup(url) in my review on the
>> previous step, but now we are making the add_url() responsible
>> for making a copy, we instead do the opposite, i.e. free alias
>> that was allocated for us because we no longer need it.
>
> Yeah. Possibly the two should be squashed. I was trying to make this
> patch a little less long/confusing, but maybe breaking things up just
> posed new questions. :)

No squashing is needed.  It's just that [02/11] could go in either
direction and the reader was held in suspense until [03/11] that
picked one direction to go ;-).

> Right. I had originally written it that way, since that would be the
> mechanical conversion. But since there was already cleanup at the bottom
> of the function, it felt more natural to shuffle it there. Which is
> correct as long as there are no other references to buf nor early
> returns. You can't see that from the context, but it is true in this
> case.

Yeah, either way it is correct, and I think the "cleanup at the end,
where the single label is there for any new error code paths to jump
to" pattern is a good approach going forward.

Looking good.

  reply	other threads:[~2024-06-17 17:43 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-09  6:51 Cannot override `remote.origin.url` with `-c` option Mathew George
2024-06-11  7:51 ` Jeff King
2024-06-11 15:28   ` Junio C Hamano
2024-06-13 10:24     ` Jeff King
2024-06-14 10:24       ` [PATCH 0/11] allow overriding remote.*.url Jeff King
2024-06-14 10:25         ` [PATCH 01/11] archive: fix check for missing url Jeff King
2024-06-14 10:26         ` [PATCH 02/11] remote: refactor alias_url() memory ownership Jeff King
2024-06-14 17:05           ` Junio C Hamano
2024-06-14 10:27         ` [PATCH 03/11] remote: transfer ownership of memory in add_url(), etc Jeff King
2024-06-14 17:04           ` Junio C Hamano
2024-06-16  4:59             ` Jeff King
2024-06-17 17:42               ` Junio C Hamano [this message]
2024-06-25 17:30           ` Elijah Newren
2024-06-14 10:28         ` [PATCH 04/11] remote: use strvecs to store remote url/pushurl Jeff King
2024-06-25 17:32           ` Elijah Newren
2024-06-14 10:29         ` [PATCH 05/11] remote: simplify url/pushurl selection Jeff King
2024-06-25 17:33           ` Elijah Newren
2024-06-14 10:30         ` [PATCH 06/11] config: document remote.*.url/pushurl interaction Jeff King
2024-06-25 17:34           ` Elijah Newren
2024-06-14 10:31         ` [PATCH 07/11] remote: allow resetting url list Jeff King
2024-06-25 17:35           ` Elijah Newren
2024-06-14 10:31         ` [PATCH 08/11] t5801: make remote-testgit GIT_DIR setup more robust Jeff King
2024-06-25 17:36           ` Elijah Newren
2024-06-14 10:34         ` [PATCH 09/11] t5801: test remote.*.vcs config Jeff King
2024-06-14 10:37         ` [PATCH 10/11] remote: always require at least one url in a remote Jeff King
2024-06-14 10:42         ` [PATCH 11/11] remote: drop checks for zero-url case Jeff King
2024-06-25 17:37           ` Elijah Newren
2024-06-25 17:44         ` [PATCH 0/11] allow overriding remote.*.url Elijah Newren
2024-06-26 20:40           ` Jeff King

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=xmqqv827a2ke.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=mathewegeorge@gmail.com \
    --cc=peff@peff.net \
    /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).