All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 6/7] repository: adapt `repo_clear()` to fully reset the repository
Date: Mon, 28 Sep 2026 11:52:06 +0200	[thread overview]
Message-ID: <aro4xkSiJDWknI1W@pks.im> (raw)
In-Reply-To: <CAOLa=ZQ_+Ofya1q01fpZjd_wDn=tk8YxbQWNxhFHya47hFRp-Q@mail.gmail.com>

On Mon, Sep 28, 2026 at 09:18:52AM +0000, Karthik Nayak wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> > diff --git a/repository.c b/repository.c
> > index b857e1c580..e67ff00550 100644
> > --- a/repository.c
> > +++ b/repository.c
> > @@ -439,6 +436,8 @@ void repo_clear(struct repository *repo)
> >  	strmap_clear(&repo->worktree_ref_stores, 1);
> >
> >  	repo_clear_path_cache(&repo->cached_paths);
> > +
> > +	memset(repo, 0, sizeof(*repo));
> 
> The reason we swap `FREE_AND_NULL()` with `free()` is because we anyways
> set everything to 0. Okay.
> 
> Or was this referring to the 'already blank' repository? Since
> FREE_AND_NULL() can already handle NULL values.

Yeah, the only reason I swap to plain free(3p) calls is because it's
redundant now with the final call to memset(3p). I think the part about
already-blank repositories is not accurate anymore, but it used to be at
one point. Let me reword it.

> > diff --git a/repository.h b/repository.h
> > index 11f5c2ed10..2a348012e8 100644
> > --- a/repository.h
> > +++ b/repository.h
> > @@ -258,6 +258,7 @@ void repo_set_ref_storage_format(struct repository *repo,
> >  void initialize_repository(struct repository *repo);
> >  RESULT_MUST_BE_USED
> >  int repo_init(struct repository *r, const char *gitdir, const char *worktree);
> > +void repo_clear(struct repository *repo);
> >
> >  /*
> >   * Initialize the repository 'subrepo' as the submodule at the given path. If
> > @@ -273,7 +274,6 @@ int repo_submodule_init(struct repository *subrepo,
> >  			struct repository *superproject,
> >  			const char *path,
> >  			const struct object_id *treeish_name);
> > -void repo_clear(struct repository *repo);
> >
> 
> This is a purely cosmetic move to bring it closer to `repo_init()`,
> right? I think it makes sense.

Yes, it is.

Patrick

  reply	other threads:[~2026-09-28  9:52 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-24  9:19 [PATCH 0/7] setup: enforce repo passed to `create_repository()` has no state Patrick Steinhardt
2026-09-24  9:19 ` [PATCH 1/7] path: drop useless `safe_create_leading_directories_1()` Patrick Steinhardt
2026-09-28  9:01   ` Karthik Nayak
2026-09-24  9:19 ` [PATCH 2/7] path: introduce `safe_create_leading_directories_no_share_const()` Patrick Steinhardt
2026-09-25 19:49   ` Kaartic Sivaraam
2026-09-28  7:15     ` Patrick Steinhardt
2026-09-28  9:21       ` Kaartic Sivaraam
2026-09-24  9:19 ` [PATCH 3/7] builtin/init: refactor messy creation of leading directories Patrick Steinhardt
2026-09-25 20:21   ` Kaartic Sivaraam
2026-09-24  9:19 ` [PATCH 4/7] builtin/init: move handling of "core.sharedRepository" into "setup.c" Patrick Steinhardt
2026-09-25 20:54   ` Kaartic Sivaraam
2026-09-28  9:13   ` Karthik Nayak
2026-09-24  9:19 ` [PATCH 5/7] builtin/clone: don't apply "core.sharedRepository" to leading dirs Patrick Steinhardt
2026-09-24  9:19 ` [PATCH 6/7] repository: adapt `repo_clear()` to fully reset the repository Patrick Steinhardt
2026-09-28  9:18   ` Karthik Nayak
2026-09-28  9:52     ` Patrick Steinhardt [this message]
2026-09-24  9:19 ` [PATCH 7/7] setup: enforce that passed-in repo does not carry relevant state Patrick Steinhardt
2026-09-25 21:08 ` [PATCH 0/7] setup: enforce repo passed to `create_repository()` has no state Kaartic Sivaraam
2026-09-28  9:20 ` Karthik Nayak
2026-09-28  9:51 ` [PATCH v2 " Patrick Steinhardt
2026-09-28  9:51   ` [PATCH v2 1/7] path: drop useless `safe_create_leading_directories_1()` Patrick Steinhardt
2026-09-28  9:51   ` [PATCH v2 2/7] path: introduce `safe_create_leading_directories_no_share_const()` Patrick Steinhardt
2026-09-28  9:51   ` [PATCH v2 3/7] builtin/init: refactor messy creation of leading directories Patrick Steinhardt
2026-09-28  9:51   ` [PATCH v2 4/7] builtin/init: move handling of "core.sharedRepository" into "setup.c" Patrick Steinhardt
2026-09-28  9:51   ` [PATCH v2 5/7] builtin/clone: don't apply "core.sharedRepository" to leading dirs Patrick Steinhardt
2026-09-28  9:51   ` [PATCH v2 6/7] repository: adapt `repo_clear()` to fully reset the repository Patrick Steinhardt
2026-09-28  9:51   ` [PATCH v2 7/7] setup: enforce that passed-in repo does not carry relevant state Patrick Steinhardt
2026-09-28 12:15   ` [PATCH v2 0/7] setup: enforce repo passed to `create_repository()` has no state Kaartic Sivaraam
2026-09-28 12:19     ` Kaartic Sivaraam
2026-09-28 12:48       ` Patrick Steinhardt
2026-09-28 15:59         ` Junio C Hamano
2026-09-28 12:48     ` Patrick Steinhardt

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=aro4xkSiJDWknI1W@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=karthik.188@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 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.