* [PATCH v6 06/11] repository: free main reference database
From: Patrick Steinhardt @ 2026-06-25 9:20 UTC (permalink / raw)
To: git; +Cc: Karthik Nayak, Jeff King, Justin Tobler
In-Reply-To: <20260625-b4-pks-refs-avoid-chdir-notify-reparent-v6-0-41fbca3cf5e3@pks.im>
While we release worktree and submodule reference databases when
clearing a repository, we don't ever release the main reference
database. This memory leak went unnoticed because its pointer is
kept alive by the "chdir_notify" subsystem.
Fix the memory leak.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
repository.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/repository.c b/repository.c
index 187dd471c4..e2b5c6712b 100644
--- a/repository.c
+++ b/repository.c
@@ -421,6 +421,11 @@ void repo_clear(struct repository *repo)
FREE_AND_NULL(repo->remote_state);
}
+ if (repo->refs_private) {
+ ref_store_release(repo->refs_private);
+ FREE_AND_NULL(repo->refs_private);
+ }
+
strmap_for_each_entry(&repo->submodule_ref_stores, &iter, e)
ref_store_release(e->value);
strmap_clear(&repo->submodule_ref_stores, 1);
--
2.55.0.rc1.745.g43192e7977.dirty
^ permalink raw reply related
* [PATCH v6 05/11] chdir-notify: drop unused `chdir_notify_reparent()`
From: Patrick Steinhardt @ 2026-06-25 9:20 UTC (permalink / raw)
To: git; +Cc: Karthik Nayak, Jeff King, Justin Tobler
In-Reply-To: <20260625-b4-pks-refs-avoid-chdir-notify-reparent-v6-0-41fbca3cf5e3@pks.im>
With the preceding commit we've removed all callers of
`chdir_notify_reparent()`, so the function is unused now. Drop it.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
chdir-notify.c | 26 --------------------------
chdir-notify.h | 6 +-----
2 files changed, 1 insertion(+), 31 deletions(-)
diff --git a/chdir-notify.c b/chdir-notify.c
index f8bfe3cbef..1237a45e2e 100644
--- a/chdir-notify.c
+++ b/chdir-notify.c
@@ -43,32 +43,6 @@ void chdir_notify_unregister(const char *name, chdir_notify_callback cb,
}
}
-static void reparent_cb(const char *name,
- const char *old_cwd,
- const char *new_cwd,
- void *data)
-{
- char **path = data;
- char *tmp = *path;
-
- if (!tmp)
- return;
-
- *path = reparent_relative_path(old_cwd, new_cwd, tmp);
- free(tmp);
-
- if (name) {
- trace_printf_key(&trace_setup_key,
- "setup: reparent %s to '%s'",
- name, *path);
- }
-}
-
-void chdir_notify_reparent(const char *name, char **path)
-{
- chdir_notify_register(name, reparent_cb, path);
-}
-
int chdir_notify(const char *new_cwd)
{
struct strbuf old_cwd = STRBUF_INIT;
diff --git a/chdir-notify.h b/chdir-notify.h
index 81eb69d846..36b4114472 100644
--- a/chdir-notify.h
+++ b/chdir-notify.h
@@ -19,10 +19,7 @@
* chdir_notify_register("description", foo, data);
*
* In practice most callers will want to move a relative path to the new root;
- * they can use the reparent_relative_path() helper for that. If that's all
- * you're doing, you can also use the convenience function:
- *
- * chdir_notify_reparent("description", &my_path);
+ * they can use the reparent_relative_path() helper for that.
*
* Whenever a chdir event occurs, that will update my_path (if it's relative)
* to adjust for the new cwd by freeing any existing string and allocating a
@@ -43,7 +40,6 @@ typedef void (*chdir_notify_callback)(const char *name,
void chdir_notify_register(const char *name, chdir_notify_callback cb, void *data);
void chdir_notify_unregister(const char *name, chdir_notify_callback cb,
void *data);
-void chdir_notify_reparent(const char *name, char **path);
/*
*
--
2.55.0.rc1.745.g43192e7977.dirty
^ permalink raw reply related
* [PATCH v6 04/11] refs: unregister reference stores from "chdir_notify"
From: Patrick Steinhardt @ 2026-06-25 9:20 UTC (permalink / raw)
To: git; +Cc: Karthik Nayak, Jeff King, Justin Tobler
In-Reply-To: <20260625-b4-pks-refs-avoid-chdir-notify-reparent-v6-0-41fbca3cf5e3@pks.im>
When creating reference stores we register them with the "chdir_notify"
subsystem. This is required because some of the paths we track may be
relative paths, so we have to reparent them in case the current working
directory changes.
But while we register the reference stores, we never unregister them.
This can have multiple outcomes:
- For a repository's main reference database we essentially keep the
pointer alive. We never free that database, either, and our leak
checker doesn't notice because it's still registered.
- For submodule and worktree reference databases we do eventually free
them in `repo_clear()`, so we may keep pointers to free'd memory
registered. We never notice though as we don't tend to chdir around
in the middle of the process.
We never noticed either of these symptoms, but they are obviously bad.
Partially fix those issues by unregistering the reference stores when
releasing them. The leak of the main reference database will be fixed in
a subsequent commit.
Note that this requires us to use `chdir_notify_register()` instead of
`chdir_notify_reparent()`, as there is no infrastructure to unregister the
latter.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
refs/files-backend.c | 22 +++++++++++++++++++---
refs/packed-backend.c | 16 +++++++++++++++-
refs/reftable-backend.c | 16 +++++++++++++++-
3 files changed, 49 insertions(+), 5 deletions(-)
diff --git a/refs/files-backend.c b/refs/files-backend.c
index a4c7858787..296981584b 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -100,6 +100,23 @@ static void clear_loose_ref_cache(struct files_ref_store *refs)
}
}
+static void files_ref_store_reparent(const char *name UNUSED,
+ const char *old_cwd,
+ const char *new_cwd,
+ void *payload)
+{
+ struct files_ref_store *refs = payload;
+ char *tmp;
+
+ tmp = reparent_relative_path(old_cwd, new_cwd, refs->base.gitdir);
+ free(refs->base.gitdir);
+ refs->base.gitdir = tmp;
+
+ tmp = reparent_relative_path(old_cwd, new_cwd, refs->gitcommondir);
+ free(refs->gitcommondir);
+ refs->gitcommondir = tmp;
+}
+
/*
* Create a new submodule ref cache and add it to the internal
* set of caches.
@@ -128,9 +145,7 @@ static struct ref_store *files_ref_store_init(struct repository *repo,
repo_config_get_bool(repo, "core.prefersymlinkrefs", &refs->prefer_symlink_refs);
- chdir_notify_reparent("files-backend $GIT_DIR", &refs->base.gitdir);
- chdir_notify_reparent("files-backend $GIT_COMMONDIR",
- &refs->gitcommondir);
+ chdir_notify_register(NULL, files_ref_store_reparent, refs);
strbuf_release(&refdir);
@@ -182,6 +197,7 @@ static void files_ref_store_release(struct ref_store *ref_store)
free(refs->gitcommondir);
ref_store_release(refs->packed_ref_store);
free(refs->packed_ref_store);
+ chdir_notify_unregister(NULL, files_ref_store_reparent, refs);
}
static void files_reflog_path(struct files_ref_store *refs,
diff --git a/refs/packed-backend.c b/refs/packed-backend.c
index 0acde48c45..499cb55dfa 100644
--- a/refs/packed-backend.c
+++ b/refs/packed-backend.c
@@ -211,6 +211,19 @@ static size_t snapshot_hexsz(const struct snapshot *snapshot)
return snapshot->refs->base.repo->hash_algo->hexsz;
}
+static void packed_ref_store_reparent(const char *name UNUSED,
+ const char *old_cwd,
+ const char *new_cwd,
+ void *payload)
+{
+ struct packed_ref_store *refs = payload;
+ char *tmp;
+
+ tmp = reparent_relative_path(old_cwd, new_cwd, refs->path);
+ free(refs->path);
+ refs->path = tmp;
+}
+
/*
* Since packed-refs is only stored in the common dir, don't parse the
* payload and rely on the files-backend to set 'gitdir' correctly.
@@ -229,7 +242,7 @@ struct ref_store *packed_ref_store_init(struct repository *repo,
strbuf_addf(&sb, "%s/packed-refs", gitdir);
refs->path = strbuf_detach(&sb, NULL);
- chdir_notify_reparent("packed-refs", &refs->path);
+ chdir_notify_register(NULL, packed_ref_store_reparent, refs);
return ref_store;
}
@@ -274,6 +287,7 @@ static void packed_ref_store_release(struct ref_store *ref_store)
clear_snapshot(refs);
rollback_lock_file(&refs->lock);
delete_tempfile(&refs->tempfile);
+ chdir_notify_unregister(NULL, packed_ref_store_reparent, refs);
free(refs->path);
}
diff --git a/refs/reftable-backend.c b/refs/reftable-backend.c
index 4ae22922de..8c93070677 100644
--- a/refs/reftable-backend.c
+++ b/refs/reftable-backend.c
@@ -365,6 +365,19 @@ static int reftable_be_config(const char *var, const char *value,
return 0;
}
+static void reftable_be_reparent(const char *name UNUSED,
+ const char *old_cwd,
+ const char *new_cwd,
+ void *payload)
+{
+ struct reftable_ref_store *refs = payload;
+ char *tmp;
+
+ tmp = reparent_relative_path(old_cwd, new_cwd, refs->base.gitdir);
+ free(refs->base.gitdir);
+ refs->base.gitdir = tmp;
+}
+
static struct ref_store *reftable_be_init(struct repository *repo,
const char *payload,
const char *gitdir,
@@ -447,7 +460,7 @@ static struct ref_store *reftable_be_init(struct repository *repo,
goto done;
}
- chdir_notify_reparent("reftables-backend $GIT_DIR", &refs->base.gitdir);
+ chdir_notify_register(NULL, reftable_be_reparent, refs);
done:
assert(refs->err != REFTABLE_API_ERROR);
@@ -474,6 +487,7 @@ static void reftable_be_release(struct ref_store *ref_store)
free(be);
}
strmap_clear(&refs->worktree_backends, 0);
+ chdir_notify_unregister(NULL, reftable_be_reparent, refs);
}
static int reftable_be_create_on_disk(struct ref_store *ref_store,
--
2.55.0.rc1.745.g43192e7977.dirty
^ permalink raw reply related
* [PATCH v6 03/11] setup: don't apply "GIT_REFERENCE_BACKEND" without a repository
From: Patrick Steinhardt @ 2026-06-25 9:20 UTC (permalink / raw)
To: git; +Cc: Karthik Nayak, Jeff King, Justin Tobler
In-Reply-To: <20260625-b4-pks-refs-avoid-chdir-notify-reparent-v6-0-41fbca3cf5e3@pks.im>
When discovering a repository we eventually also apply the
"GIT_REFERENCE_BACKEND" environment variable to the repository. There's
two problems with that:
- We do this unconditionally, which is rather pointless: we really
only have to configure the repository when we have found one.
- We have already applied the repository format at that point in time,
so we need to manually reapply it.
Move the logic around so that we only apply the environment variable
when a repository was discovered. This also allows us to drop the
explcit call to `repo_set_ref_storage_format()` because we now adjust
the format before we apply it via `apply_repository_format()`.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
setup.c | 39 +++++++++++++++++++--------------------
1 file changed, 19 insertions(+), 20 deletions(-)
diff --git a/setup.c b/setup.c
index 2748155964..79125db565 100644
--- a/setup.c
+++ b/setup.c
@@ -1906,7 +1906,6 @@ const char *setup_git_directory_gently(struct repository *repo, int *nongit_ok)
static struct strbuf cwd = STRBUF_INIT;
struct strbuf dir = STRBUF_INIT, gitdir = STRBUF_INIT, report = STRBUF_INIT;
const char *prefix = NULL;
- const char *ref_backend_uri;
struct repository_format repo_fmt = REPOSITORY_FORMAT_INIT;
/*
@@ -2032,6 +2031,25 @@ const char *setup_git_directory_gently(struct repository *repo, int *nongit_ok)
if (startup_info->have_repository) {
struct strbuf err = STRBUF_INIT;
+ const char *ref_backend_uri;
+
+ /*
+ * The env variable should override the repository config
+ * for 'extensions.refStorage'.
+ */
+ ref_backend_uri = getenv(GIT_REFERENCE_BACKEND_ENVIRONMENT);
+ if (ref_backend_uri) {
+ char *format;
+
+ free(repo_fmt.ref_storage_payload);
+
+ parse_reference_uri(ref_backend_uri, &format, &repo_fmt.ref_storage_payload);
+ repo_fmt.ref_storage_format = ref_storage_format_by_name(format);
+ if (repo_fmt.ref_storage_format == REF_STORAGE_FORMAT_UNKNOWN)
+ die(_("unknown ref storage format: '%s'"), format);
+
+ free(format);
+ }
if (apply_repository_format(repo, &repo_fmt,
APPLY_REPOSITORY_FORMAT_HONOR_ENV, &err) < 0)
@@ -2057,25 +2075,6 @@ const char *setup_git_directory_gently(struct repository *repo, int *nongit_ok)
setenv(GIT_PREFIX_ENVIRONMENT, "", 1);
}
- /*
- * The env variable should override the repository config
- * for 'extensions.refStorage'.
- */
- ref_backend_uri = getenv(GIT_REFERENCE_BACKEND_ENVIRONMENT);
- if (ref_backend_uri) {
- char *backend, *payload;
- enum ref_storage_format format;
-
- parse_reference_uri(ref_backend_uri, &backend, &payload);
- format = ref_storage_format_by_name(backend);
- if (format == REF_STORAGE_FORMAT_UNKNOWN)
- die(_("unknown ref storage format: '%s'"), backend);
- repo_set_ref_storage_format(repo, format, payload);
-
- free(backend);
- free(payload);
- }
-
setup_original_cwd(repo);
strbuf_release(&dir);
--
2.55.0.rc1.745.g43192e7977.dirty
^ permalink raw reply related
* [PATCH v6 02/11] setup: stop applying repository format twice
From: Patrick Steinhardt @ 2026-06-25 9:20 UTC (permalink / raw)
To: git; +Cc: Karthik Nayak, Jeff King, Justin Tobler
In-Reply-To: <20260625-b4-pks-refs-avoid-chdir-notify-reparent-v6-0-41fbca3cf5e3@pks.im>
When discovering the repository in "setup.c" we apply the final
repository format multiple times:
- Once via `repository_format_configure()`, where we apply the hash
algorithm and ref storage format to both `struct repository_format`
and `struct repository`.
- And once via `apply_repository_format()`, where we apply these two
settings from `struct repository_format` to `struct repository`.
With the current flow both of these are in fact necessary. But this is
only because we call `repository_format_configure()` after we have
called `apply_repository_format()`. Consequently, if we only changed the
repository format in `repository_format_configure()` it would never
propagate to the repository.
Refactor the code so that we first configure the repository format
before applying it to the repository so that we can stop setting the
hash and reference storage format multiple times.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
setup.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/setup.c b/setup.c
index a9db1f2c23..2748155964 100644
--- a/setup.c
+++ b/setup.c
@@ -2710,8 +2710,7 @@ static int read_default_format_config(const char *key, const char *value,
return ret;
}
-static void repository_format_configure(struct repository *repo,
- struct repository_format *repo_fmt,
+static void repository_format_configure(struct repository_format *repo_fmt,
int hash, enum ref_storage_format ref_format)
{
struct default_format_config cfg = {
@@ -2748,7 +2747,6 @@ static void repository_format_configure(struct repository *repo,
} else if (cfg.hash != GIT_HASH_UNKNOWN) {
repo_fmt->hash_algo = cfg.hash;
}
- repo_set_hash_algo(repo, repo_fmt->hash_algo);
env = getenv("GIT_DEFAULT_REF_FORMAT");
if (repo_fmt->version >= 0 &&
@@ -2786,9 +2784,6 @@ static void repository_format_configure(struct repository *repo,
free(backend);
}
-
- repo_set_ref_storage_format(repo, repo_fmt->ref_storage_format,
- repo_fmt->ref_storage_payload);
}
int init_db(struct repository *repo,
@@ -2830,10 +2825,10 @@ int init_db(struct repository *repo,
* is an attempt to reinitialize new repository with an old tool.
*/
check_repository_format_gently(repo_get_git_dir(repo), &repo_fmt, NULL);
+ repository_format_configure(&repo_fmt, hash, ref_storage_format);
if (apply_repository_format(repo, &repo_fmt, APPLY_REPOSITORY_FORMAT_HONOR_ENV, &err) < 0)
die("%s", err.buf);
startup_info->have_repository = 1;
- repository_format_configure(repo, &repo_fmt, hash, ref_storage_format);
/*
* Ensure `core.hidedotfiles` is processed. This must happen after we
--
2.55.0.rc1.745.g43192e7977.dirty
^ permalink raw reply related
* [PATCH v6 01/11] setup: inline `check_and_apply_repository_format()`
From: Patrick Steinhardt @ 2026-06-25 9:19 UTC (permalink / raw)
To: git; +Cc: Karthik Nayak, Jeff King, Justin Tobler
In-Reply-To: <20260625-b4-pks-refs-avoid-chdir-notify-reparent-v6-0-41fbca3cf5e3@pks.im>
We have two callsites of `check_and_apply_repository_format()`. In a
subsequent commit we'll want to adapt one of those callsites to change
the order in which we read and apply the repository format, at which
point the helper function will not really be a good fit for us anymore.
Inline the function to both of the callsites.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
setup.c | 47 ++++++++++++++++-------------------------------
1 file changed, 16 insertions(+), 31 deletions(-)
diff --git a/setup.c b/setup.c
index b4652651df..a9db1f2c23 100644
--- a/setup.c
+++ b/setup.c
@@ -1788,32 +1788,6 @@ int apply_repository_format(struct repository *repo,
return 0;
}
-/*
- * Check the repository format version in the path found in repo_get_git_dir(repo),
- * and die if it is a version we don't understand. Generally one would
- * set_git_dir() before calling this, and use it only for "are we in a valid
- * repo?".
- *
- * If successful and fmt is not NULL, fill fmt with data.
- */
-static void check_and_apply_repository_format(struct repository *repo,
- struct repository_format *fmt,
- enum apply_repository_format_flags flags)
-{
- struct repository_format repo_fmt = REPOSITORY_FORMAT_INIT;
- struct strbuf err = STRBUF_INIT;
-
- if (!fmt)
- fmt = &repo_fmt;
-
- check_repository_format_gently(repo_get_git_dir(repo), fmt, NULL);
- if (apply_repository_format(repo, fmt, flags, &err) < 0)
- die("%s", err.buf);
- startup_info->have_repository = 1;
-
- clear_repository_format(&repo_fmt);
-}
-
const char *enter_repo(struct repository *repo, const char *path, unsigned flags)
{
static struct strbuf validated_path = STRBUF_INIT;
@@ -1887,9 +1861,17 @@ const char *enter_repo(struct repository *repo, const char *path, unsigned flags
}
if (is_git_directory(".")) {
+ struct repository_format fmt = REPOSITORY_FORMAT_INIT;
+ struct strbuf err = STRBUF_INIT;
+
set_git_dir(repo, ".", 0);
- check_and_apply_repository_format(repo, NULL,
- APPLY_REPOSITORY_FORMAT_HONOR_ENV);
+ check_repository_format_gently(".", &fmt, NULL);
+ if (apply_repository_format(repo, &fmt, APPLY_REPOSITORY_FORMAT_HONOR_ENV, &err) < 0)
+ die("%s", err.buf);
+ startup_info->have_repository = 1;
+
+ clear_repository_format(&fmt);
+ strbuf_release(&err);
return path;
}
@@ -2820,6 +2802,7 @@ int init_db(struct repository *repo,
int exist_ok = flags & INIT_DB_EXIST_OK;
char *original_git_dir = real_pathdup(git_dir, 1);
struct repository_format repo_fmt = REPOSITORY_FORMAT_INIT;
+ struct strbuf err = STRBUF_INIT;
if (real_git_dir) {
struct stat st;
@@ -2846,9 +2829,10 @@ int init_db(struct repository *repo,
* config file, so this will not fail. What we are catching
* is an attempt to reinitialize new repository with an old tool.
*/
- check_and_apply_repository_format(repo, &repo_fmt,
- APPLY_REPOSITORY_FORMAT_HONOR_ENV);
-
+ check_repository_format_gently(repo_get_git_dir(repo), &repo_fmt, NULL);
+ if (apply_repository_format(repo, &repo_fmt, APPLY_REPOSITORY_FORMAT_HONOR_ENV, &err) < 0)
+ die("%s", err.buf);
+ startup_info->have_repository = 1;
repository_format_configure(repo, &repo_fmt, hash, ref_storage_format);
/*
@@ -2904,6 +2888,7 @@ int init_db(struct repository *repo,
}
clear_repository_format(&repo_fmt);
+ strbuf_release(&err);
free(original_git_dir);
return 0;
}
--
2.55.0.rc1.745.g43192e7977.dirty
^ permalink raw reply related
* [PATCH v6 00/11] refs: fix "onbranch" conditions
From: Patrick Steinhardt @ 2026-06-25 9:19 UTC (permalink / raw)
To: git; +Cc: Karthik Nayak, Jeff King, Justin Tobler
In-Reply-To: <20260610-b4-pks-refs-avoid-chdir-notify-reparent-v1-0-56c864b01c43@pks.im>
Hi,
originally, this patch series was a follow-up of the discussion at [1],
where it converted the reference backends to always use absolute paths
internally so that we could drop the `chdir_notify_reparent()`
machinery. But this focus shifted as we discovered that this led to
quite a sizeable performance regression.
Instead, the series now focusses on fixing handling of the "onbranch"
conditions. As part of the above work I discovered that we recurse when
creating the main reference database in case we have "onbranch"
conditions, and that recursion caused us to construct an ad-hoc
reference store that we essentially discarded. The leak wasn't ever
catched though because the store is kept alive by the `chdir_notify`
infrastructure.
This is a deeper-running issue though: the reference backends respect
some configuration guarded by "onbranch" conditions, but not all of
them. This issue is fixed by this series by lazy-loading all
configuration so that we don't need to read any configuration when we
initialize the reference store. This fixes the recursion and makes us
consistently honor those "onbranch" conditions.
This series is built on top of 1ff279f340 (The 13th batch, 2026-06-09)
with ps/setup-centralize-odb-creation at 42b9d3dc9d (setup: construct
object database in `apply_repository_format()`, 2026-06-04) merged into
it.
Changes in v6:
- Drop redundant condition when setting the default for
"core.logallrefupdates".
- Leave breakcrumb for why we lazy-load write options for the "files"
backend.
- Fix commit message typo.
- Link to v5: https://patch.msgid.link/20260622-b4-pks-refs-avoid-chdir-notify-reparent-v5-0-018475013dbc@pks.im
Changes in v5:
- Fix the "onbranch" recursion properly: instead of papering over the
issue, this series now refactors reference store initialization to
not read any configuration at all anymore. Instead, the config is
now parsed lazily. This fixes the recursion, but also makes us
respect configuration guarded by "onbranch" conditions properly.
- Link to v4: https://patch.msgid.link/20260619-b4-pks-refs-avoid-chdir-notify-reparent-v4-0-a6472be7acc4@pks.im
Changes in v4:
- Fix the "onbranch" recursion at the root of the problem by
explicitly disabling the use of the ref store when parsing
configuration at ref store initialization time.
- Link to v3: https://patch.msgid.link/20260618-b4-pks-refs-avoid-chdir-notify-reparent-v3-0-2a5669e8f486@pks.im
Changes in v3:
- Reduce the scope of applying the GIT_REFERENCE_BACKEND environment
variable even further so that we really only do this when we end up
applying the reference format.
- Fix a commit message that still referred to the dropped last commit.
- Link to v2: https://patch.msgid.link/20260615-b4-pks-refs-avoid-chdir-notify-reparent-v2-0-f4854aa99859@pks.im
Changes in v2:
- Drop the last patch. This seemingly destroys the whole purpose of
the patch series, but after Peff's hint that this is actually a
performance optimization I'm less inclined to drop the chdir_notify
infra. I still think that the remainder of the patches make sense
standalone, as they simplify "setup.c" and clean memory leaks. Going
forward I'd like to investigate the idea of introducing a `struct
fsroot` infrastructure that uses the platform-equivalent of openat
et al.
- Improve a couple of commit messages.
- Link to v1: https://patch.msgid.link/20260610-b4-pks-refs-avoid-chdir-notify-reparent-v1-0-56c864b01c43@pks.im
Thanks!
Patrick
[1]: <aifAVpxanV31KUpC@pks.im>
---
Patrick Steinhardt (11):
setup: inline `check_and_apply_repository_format()`
setup: stop applying repository format twice
setup: don't apply "GIT_REFERENCE_BACKEND" without a repository
refs: unregister reference stores from "chdir_notify"
chdir-notify: drop unused `chdir_notify_reparent()`
repository: free main reference database
refs: move parsing of "core.logAllRefUpdates" back into ref stores
refs/files: lazy-load configuration to fix chicken-and-egg
reftable: split up write options
refs/reftable: lazy-load configuration to fix chicken-and-egg
refs: protect against chicken-and-egg recursion
builtin/checkout.c | 7 +-
chdir-notify.c | 26 -----
chdir-notify.h | 6 +-
refs.c | 17 +++-
refs.h | 9 ++
refs/files-backend.c | 76 ++++++++++++---
refs/packed-backend.c | 16 ++-
refs/refs-internal.h | 6 --
refs/reftable-backend.c | 177 ++++++++++++++++++++-------------
reftable/reftable-stack.h | 30 +++++-
reftable/reftable-writer.h | 17 +---
reftable/stack.c | 100 ++++++++++++-------
reftable/stack.h | 2 +-
reftable/writer.c | 21 ++--
reftable/writer.h | 1 +
repo-settings.c | 16 ---
repo-settings.h | 9 --
repository.c | 5 +
setup.c | 101 ++++++++-----------
t/helper/test-reftable.c | 2 +-
t/t0600-reffiles-backend.sh | 21 ++++
t/t0613-reftable-write-options.sh | 19 ++++
t/t1400-update-ref.sh | 12 +++
t/unit-tests/lib-reftable.c | 8 +-
t/unit-tests/lib-reftable.h | 2 +
t/unit-tests/u-reftable-merged.c | 9 +-
t/unit-tests/u-reftable-readwrite.c | 38 ++++++--
t/unit-tests/u-reftable-stack.c | 189 ++++++++++++++++--------------------
t/unit-tests/u-reftable-table.c | 8 +-
29 files changed, 561 insertions(+), 389 deletions(-)
Range-diff versus v5:
1: 27cb4688d9 = 1: 9281850ec4 setup: inline `check_and_apply_repository_format()`
2: f0e9e95c25 = 2: cdd6a01554 setup: stop applying repository format twice
3: b3ecceae2e = 3: 748506f661 setup: don't apply "GIT_REFERENCE_BACKEND" without a repository
4: 8d70b43f8c = 4: 9ffc2e94c6 refs: unregister reference stores from "chdir_notify"
5: 190956a8f6 = 5: 080e7d175f chdir-notify: drop unused `chdir_notify_reparent()`
6: 504a0326c3 = 6: 5a2b973766 repository: free main reference database
7: 2f0ecfd9d9 ! 7: ecdbf37fde refs: move parsing of "core.logAllRefUpdates" back into ref stores
@@ setup.c: static int create_default_files(struct repository *repo,
+
/* allow template config file to override the default */
- if (repo_settings_get_log_all_ref_updates(repo) == LOG_REFS_UNSET)
-+ if (repo_config_get_string_tmp(repo, "core.logallrefupdates", &value) ||
-+ refs_parse_log_all_ref_updates_config(value) == LOG_REFS_UNSET)
++ if (repo_config_get_string_tmp(repo, "core.logallrefupdates", &value))
repo_config_set(repo, "core.logallrefupdates", "true");
+
if (needs_work_tree_config(original_git_dir, work_tree))
8: ea171d971d ! 8: 618df32bb6 refs/files: lazy-load configuration to fix chicken-and-egg
@@ refs/files-backend.c: struct files_ref_store {
-
struct ref_store *packed_ref_store;
+
++ /*
++ * Options used when writing references. These are parsed from the
++ * config lazily on first use via `files_ref_store_write_options()` so
++ * that we don't have to access the configuration when initializing the
++ * ref store. Do not access these fields directly, but use the accessor
++ * instead.
++ */
+ struct files_ref_store_write_options {
+ enum log_refs_config log_all_ref_updates;
+ int prefer_symlink_refs;
9: e3bb0c90ef = 9: 13b14f9394 reftable: split up write options
10: 74b389c2f1 ! 10: ba12b6f164 refs/reftable: lazy-load configuration to fix chicken-and-egg
@@ Commit message
properly, add a generic test to t1400 that verifies that the user can
configure "core.logAllRefUpdates" via an "onbranch" condition. This is
mostly a nonsensical thing to do in the first place, but it serves as a
- good sanity chekc.
+ good sanity check.
Note that we had to move `should_write_log()` around so that it can
access the new `reftable_be_write_options()` function.
11: 0cb5a85167 = 11: 85a675ada9 refs: protect against chicken-and-egg recursion
---
base-commit: 255322df35357168daefec8523a3cdc849edd6c1
change-id: 20260609-b4-pks-refs-avoid-chdir-notify-reparent-a4eaf1edbcab
^ permalink raw reply
* Re: [PATCH v14 2/2] checkout: extend --track with a "fetch" mode to refresh start-point
From: Kristofer Karlsson @ 2026-06-25 9:15 UTC (permalink / raw)
To: Harald Nordgren
Cc: Ben Knoble, Junio C Hamano, phillip.wood,
Harald Nordgren via GitGitGadget, git, Ramsay Jones,
Kristoffer Haugsbakk, Marc Branchaud
In-Reply-To: <CAHwyqnWdsYGHMcMT=B-Vdrb_DUK61QBs0-YvWkdeq958v_r35w@mail.gmail.com>
On Thu, 25 Jun 2026 at 10:54, Harald Nordgren <haraldnordgren@gmail.com> wrote:
>
> Hi!
>
> I think you are touching on the critical point here; Git is likely one
> of the most ordered software projects that exist (I haven't worked on
> Linux kernel but that's the only one I can imagine is more stringent),
> and every "real job" I had has been fast-paced and chaotic.
>
> I believe that we must leave the ivory tower and make Git great for
> the real world.
>
I wouldn't call it an ivory tower, but rather a very solid foundation
of useful primitives that can be composed and extended by higher level
workflows. I think this is a good thing. The git core is kept clean
and simple and it provides hooks and tooling to allow for customization.
For the combination of fetch and checkout, it seems easy enough to add
as a git alias:
[alias]
newtopic = "!f() { git fetch origin master && git checkout -b
\"$1\" FETCH_HEAD; }; f"
I think the usecase is valid, but I think it can be cleanly added on top of git
instead of changing git.
- Kristofer
^ permalink raw reply
* Re: [PATCH v14 2/2] checkout: extend --track with a "fetch" mode to refresh start-point
From: Harald Nordgren @ 2026-06-25 8:53 UTC (permalink / raw)
To: Ben Knoble
Cc: Junio C Hamano, phillip.wood, Harald Nordgren via GitGitGadget,
git, Ramsay Jones, Kristoffer Haugsbakk, Marc Branchaud
In-Reply-To: <43C04FB5-7FE5-4535-A79A-C35449EB38C0@gmail.com>
Hi!
I think you are touching on the critical point here; Git is likely one
of the most ordered software projects that exist (I haven't worked on
Linux kernel but that's the only one I can imagine is more stringent),
and every "real job" I had has been fast-paced and chaotic.
I believe that we must leave the ivory tower and make Git great for
the real world.
> I also fetch several times a day to keep up to date locally
I think this is also something that makes you not feel the pain as
much. As a technical leader who spends time on reviewing, it gives a
more of a aloof/holistic view. And more likely to have already fetched
the latest master at any given point. When I worked as an IC, I forked
from a stale branch 1000's of times and often felt that pain, I would
have wished for this feature.
> So « bad workflow » I agree with, but am plenty guilty of :)
Is it "bad", or is it just a completely normal workflow for 99% of
developers? Maybe we should cater to the normal workflow rather than
chastising them.
> To wrap up, I wonder if the convenience of this proposal is especially aimed at folks like my corporate environment (where « build near the tip and integrate quickly » is the norm), but less than useful for those same folks in a different situation?
Sure, we can say that, but that's likely 99% of all Git users?
Harald
Harald
^ permalink raw reply
* Re: [PATCH v2 2/2] push: suggest <remote> <branch> for a slash slip
From: Harald Nordgren @ 2026-06-25 7:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Harald Nordgren via GitGitGadget, git
In-Reply-To: <xmqq1pdvgukt.fsf@gitster.g>
> Junio C Hamano <gitster@pobox.com> writes:
>
> > "Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> >
> >> diff --git a/t/t5529-push-errors.sh b/t/t5529-push-errors.sh
> >> index 80b06a0cd2..cfb294305d 100755
> >> --- a/t/t5529-push-errors.sh
> >> +++ b/t/t5529-push-errors.sh
> >> @@ -54,6 +54,37 @@ test_expect_success 'detect empty remote with targeted refspec' '
> >> grep "fatal: bad repository ${SQ}${SQ}" stderr
> >> '
> > t5529-push-errors.sh:59: error: bare grep outside pipeline (use test_grep)
> > t5529-push-errors.sh:60: error: bare grep outside pipeline (use test_grep)
> > t5529-push-errors.sh:62: error: bare grep outside pipeline (use test_grep)
> > t5529-push-errors.sh:67: error: bare grep outside pipeline (use test_grep)
> > t5529-push-errors.sh:72: error: bare grep outside pipeline (use test_grep)
> > t5529-push-errors.sh:77: error: bare grep outside pipeline (use test_grep)
> > t5529-push-errors.sh:84: error: bare grep outside pipeline (use test_grep)
>
> I've queued this squashable? fix on top of the branch before merging
> the result to 'seen' for tonight's push-out.
>
> Thanks.
Thank you!
Is someone working on fixing the GitHub CI? I used to rely on it
before, it would have caught this, and now I'm relying on "if less
than five GitHub CI tests are failing (with the 4GB warning) and tests
are passing locally, then I can submit" which is admittedly not a good
heuristic.
Harald
^ permalink raw reply
* Re: [PATCH v2 1/2] branch: suggest <remote>/<branch> on upstream slip
From: Harald Nordgren @ 2026-06-25 7:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Harald Nordgren via GitGitGadget, git
In-Reply-To: <xmqqechvh8m8.fsf@gitster.g>
> Do we still need the _if_enabled() thing here? Isn't the caller
> gated with the same condition in this version?
>
> > + strbuf_release(&remote_ref);
> > + exit(code);
> > +}
> > +
> > int cmd_branch(int argc,
> > const char **argv,
> > const char *prefix,
> > @@ -957,6 +980,9 @@ int cmd_branch(int argc,
> > if (!refs_ref_exists(get_main_ref_store(the_repository), branch->refname)) {
> > if (!argc || branch_checked_out(branch->refname))
> > die(_("no commit on branch '%s' yet"), branch->name);
> > + if (argc == 1 &&
> > + advice_enabled(ADVICE_SET_UPSTREAM_FAILURE))
> > + die_if_upstream_looks_like_remote(new_upstream, argv[0]);
> > die(_("branch '%s' does not exist"), branch->name);
> > }
I think we do, so it will give the advice and tell the user that it
can be disabled in the standard format.
Harald
^ permalink raw reply
* Re: [PATCH v3 0/2] doc: clarify review replies and reroll timing
From: Weijie Yuan @ 2026-06-25 6:54 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, gitster
In-Reply-To: <ajvDuUiDsmyf5LnX@pks.im>
On Wed, Jun 24, 2026 at 01:47:05PM +0200, Patrick Steinhardt wrote:
> On Sun, Jun 21, 2026 at 04:04:36PM +0800, Weijie Yuan wrote:
> > Changes in v3:
> >
> > - Reworked the substantial-rework case. Instead of suggesting that
> > authors send a new version sooner, the text now advises authors not
> > to rush out an updated version before reviewing the larger changes
> > carefully. It recommends replying to the review that prompted the
> > rewrite, saying that a substantial rework is planned, and pointing
> > out which parts of the current series will become obsolete.
> >
> > - Dropped the advice that a topic close to being accepted may justify
> > a quicker reroll.
> >
> > - Removed "how close the topic is to being accepted" from the short
> > reroll-timing guidance in Documentation/SubmittingPatches.
> >
> > - Updated the commit message of patch 2 accordingly.
>
> I'm happy with this version, thanks!
>
> Patrick
Thank you very much for your review and guidance!
^ permalink raw reply
* Re: [PATCH v2 2/2] doc: advise batching patch rerolls
From: Weijie Yuan @ 2026-06-25 6:53 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: Junio C Hamano, git
In-Reply-To: <ajvDrjk-bTvYaQtU@pks.im>
On Wed, Jun 24, 2026 at 01:46:54PM +0200, Patrick Steinhardt wrote:
> > But here I think Patrick's original intention is: If your series is
> > *close* to be accepted, (while I'm not sure what the precise definition
> > of this "close to be accepted", does it means: commented by Junio with
> > "Looks good", or reviewed by the community/core contributors with "Makes
> > sense"?) and this time there happens to be a small issue, you can
> > re-roll quickly to make your series more "sturdy" to wait for
> > maintainer's final examination and further merges.
> >
> > So, I think the situation you are describing here is that this version
> > of the patch has already been declared by the *author* to be the final
> > version. (i.e. waiting for Junio to do the last exam)
>
> My "close to be accepted" feeling is when you've had multiple rounds of
> design discussions already, everyone is on the same page, and all you
> got on the last review round is a couple of typo fixes.
>
> But all of this is highly subjective, so it'll always depend and it
> won't be easy to codify all of that. Nor is that necessary, I guess. We
> really only want to provide some rough guidance.
Agreed, thanks!
> > Therefore, I do not think the two situations conflict with each other,
> > or are directly related. One concerns a patch that is already close to
> > receiving the maintainer's final verdict, where a minor issue is
> > discovered and the author quickly rerolls it. The other concerns an
> > author who, without realizing that some issues remain unresolved, rushes
> > to send what they believe to be the final version and then waits for the
> > maintainer to review it.
> >
> > For the latter case, I think it would be better to add a sentence along
> > the lines of: "Before sending a new version/the final version, check
> > once more whether there are any unresolved issues," if the existing
> > documentation does not already make this clear.
>
> I think that should mostly be clear with our documentation. And
> eventually, we should also expect people to have some common sense :)
Agreed.
> > That said, I am not familiar with how patch discussions have played out
> > in the past, so please directly point out any mistakes in my
> > understanding. I have to admit that, by this point in writing the
> > message, I have become a little tangled up in my own reasoning.
>
> I guess that's kind of expected, mostly because many of these things are
> highly subjective and will depend on the situation. The guidance does
> not have to be perfect, you'll probably be able to find counterexamples
> for many of the cases.
Yes, setting the rules too strictly may actually reduce flexibility of
our project.
Thanks!
^ permalink raw reply
* Re: [PATCH v5 10/11] refs/reftable: lazy-load configuration to fix chicken-and-egg
From: Patrick Steinhardt @ 2026-06-25 6:36 UTC (permalink / raw)
To: Justin Tobler; +Cc: git, Karthik Nayak, Jeff King
In-Reply-To: <ajxU-McoGrfkeKTs@denethor>
On Wed, Jun 24, 2026 at 05:18:21PM -0500, Justin Tobler wrote:
> On 26/06/22 10:28AM, Patrick Steinhardt wrote:
> > diff --git a/refs/reftable-backend.c b/refs/reftable-backend.c
> > index 608d71cf10..d74131a5ae 100644
> > --- a/refs/reftable-backend.c
> > +++ b/refs/reftable-backend.c
> > @@ -141,10 +141,21 @@ struct reftable_ref_store {
> > */
> > struct strmap worktree_backends;
> > struct reftable_stack_options stack_options;
> > - struct reftable_write_options write_options;
> > +
> > + /*
> > + * Options used when writing to or compacting the reftable stacks.
> > + * These are parsed from the configuration lazily on first use via
> > + * `reftable_be_write_options()` so that we don't have to access the
> > + * configuration when initializing the ref store. Do not access these
> > + * fields directly, but use the accessor instead.
> > + */
> > + struct reftable_be_write_options {
> > + struct reftable_write_options opts;
> > + enum log_refs_config log_all_ref_updates;
>
> Any reason in particular that `log_all_ref_updates` is the only option
> outside of `struct reftlable_write_options` here? Isn't it also only
> used during writes?
`log_all_ref_updates` is part of the backend's logic, whereas the
`struct reftable_write_options` is part of the reftable library's logic.
So they have different scopes, and the former cannot be handled in the
library.
Patrick
^ permalink raw reply
* Re: [PATCH v5 09/11] reftable: split up write options
From: Patrick Steinhardt @ 2026-06-25 6:35 UTC (permalink / raw)
To: Justin Tobler; +Cc: git, Karthik Nayak, Jeff King
In-Reply-To: <ajxR2fLRsIvNYFtz@denethor>
On Wed, Jun 24, 2026 at 05:06:32PM -0500, Justin Tobler wrote:
> On 26/06/22 10:28AM, Patrick Steinhardt wrote:
> > When initializing the reftable stack the caller may optionally pass some
> > write options. These write options mix up two different concerns though:
> >
> > - Of course, they allow the caller to configure how new reftables are
> > being written.
> >
> > - But they also allow the caller to configure the stack itself, like
> > its hash ID and the `on_reload` callback.
> >
> > This is somewhat awkward, as it doesn't easily give the caller the
> > flexibility to for example write multiple reftables with different
> > options. Furthermore, this requires us to eagerly parse relevant
> > configuration when initializing the reftable backend.
>
> Naive question: are there any current use cases where callers may want
> to write multiple reftables with a different set of options? Can
> reftables written with different options pose any correctness issues?
There aren't, but in theory it's totally fine to do it. One could for
example imagine that a large reference transaction wants to use a larger
block size with a different restart interval.
The only thing that of course shouldn't happen is that the different
tables use different hashes.
Patrick
^ permalink raw reply
* Re: [PATCH v5 08/11] refs/files: lazy-load configuration to fix chicken-and-egg
From: Patrick Steinhardt @ 2026-06-25 6:35 UTC (permalink / raw)
To: Justin Tobler; +Cc: git, Karthik Nayak, Jeff King
In-Reply-To: <ajxKh-IrC2EPWJnW@denethor>
On Wed, Jun 24, 2026 at 04:36:28PM -0500, Justin Tobler wrote:
> On 26/06/22 10:28AM, Patrick Steinhardt wrote:
> > diff --git a/refs/files-backend.c b/refs/files-backend.c
> > index 79fb6735e1..d0f379dcd6 100644
> > --- a/refs/files-backend.c
> > +++ b/refs/files-backend.c
> > @@ -84,12 +84,14 @@ struct files_ref_store {
> > unsigned int store_flags;
> >
> > char *gitcommondir;
> > - enum log_refs_config log_all_ref_updates;
> > - int prefer_symlink_refs;
> > -
> > struct ref_cache *loose;
> > -
> > struct ref_store *packed_ref_store;
> > +
> > + struct files_ref_store_write_options {
> > + enum log_refs_config log_all_ref_updates;
> > + int prefer_symlink_refs;
> > + bool initialized;
> > + } write_opts_lazy_loaded;
>
> It might be nice to leave some sort of breadcrumb comment to future
> readers to explain why we lazy load this configuration.
Fair, will do.
Patrick
^ permalink raw reply
* Re: [PATCH v5 07/11] refs: move parsing of "core.logAllRefUpdates" back into ref stores
From: Patrick Steinhardt @ 2026-06-25 6:35 UTC (permalink / raw)
To: Justin Tobler; +Cc: git, Karthik Nayak, Jeff King
In-Reply-To: <ajxEXMTBmii01dVP@denethor>
On Wed, Jun 24, 2026 at 04:22:07PM -0500, Justin Tobler wrote:
> On 26/06/22 10:28AM, Patrick Steinhardt wrote:
> > diff --git a/setup.c b/setup.c
> > index 79125db565..0c6efb0560 100644
> > --- a/setup.c
> > +++ b/setup.c
> > @@ -2584,10 +2584,15 @@ static int create_default_files(struct repository *repo,
> > if (is_bare_repository())
> > repo_config_set(repo, "core.bare", "true");
> > else {
> > + const char *value;
> > +
> > repo_config_set(repo, "core.bare", "false");
> > +
> > /* allow template config file to override the default */
> > - if (repo_settings_get_log_all_ref_updates(repo) == LOG_REFS_UNSET)
> > + if (repo_config_get_string_tmp(repo, "core.logallrefupdates", &value) ||
> > + refs_parse_log_all_ref_updates_config(value) == LOG_REFS_UNSET)
>
> Huh, can `refs_parse_log_all_ref_updates_config()` even return
> LOG_REFS_UNSET?
It can't, so the second statement is really redundant. All that we care
about there is that the configuration isn't already set, which is
already covered by the first statement.
Will adapt.
Patrick
^ permalink raw reply
* Re: [PATCH v2 4/4] connected: search promisor objects generically
From: Patrick Steinhardt @ 2026-06-25 5:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Christian Couder
In-Reply-To: <xmqqjyrnkinn.fsf@gitster.g>
On Wed, Jun 24, 2026 at 09:27:56AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> > diff --git a/connected.c b/connected.c
> > index d2b334173f..b557ff5db9 100644
> > --- a/connected.c
> > +++ b/connected.c
> > @@ -11,6 +11,13 @@
> > #include "packfile.h"
> > #include "promisor-remote.h"
> >
> > +static int promised_object_cb(const struct object_id *oid UNUSED,
> > + struct object_info *oi UNUSED,
> > + void *payload UNUSED)
> > +{
> > + return 1;
> > +}
> > +
> > /*
> > * For partial clones, we don't want to have to do a regular connectivity check
> > * because we have to enumerate and exclude all promisor objects (slow), and
> > @@ -30,25 +37,28 @@ static int check_connected_promisor(oid_iterate_fn fn,
> > void *cb_data,
> > const struct object_id **oid)
> > {
> > + struct odb_for_each_object_options opts = {
> > + .flags = ODB_FOR_EACH_OBJECT_PROMISOR_ONLY,
> > + .prefix_hex_len = the_repository->hash_algo->hexsz,
> > + };
> > + int err;
> > +
> > odb_reprepare(the_repository->objects);
> > do {
> > - struct packed_git *p;
> > + opts.prefix = *oid;
> >
> > - repo_for_each_pack(the_repository, p) {
> > - if (!p->pack_promisor)
> > - continue;
> > - if (find_pack_entry_one(*oid, p))
> > - goto promisor_pack_found;
> > - }
> > + err = odb_for_each_object_ext(the_repository->objects,
> > + NULL, promised_object_cb,
> > + NULL, &opts);
>
> promised_object_cb() returns 1 without any computation since we are
> only interested in learning ODB_FOR_EACH_OBJECT_PROMISOR_ONLY finds
> any such object.
>
> odb_for_each_object_ext() returns 0 (if it iterates all the sources
> to the end), but if its call to odb_source_for_each_object() yields
> non-zero value, the returned value comes back as "err" here,
> terminating the for-each iteration immediately.
>
> odb_source_for_each_object() is implemented differently per the
> source backend, but taking an example of "packfile" backend,
> packfile_loose_for_each_object() ends up calling cb (wrapped in
> packfile_store_for_each_object_wrapper_data) via
> for_each_object_in_pack(), which stops immediately when cb returns
> non-zero and the value returned from there is the value given by cb,
> i.e., 1. So we will have err==1 when we find any object.
>
> > + if (err < 0)
> > + return err;
>
> And err presumably is 1 in such a case, so this does not trigger.
>
> > /*
> > * We have found an object that is not part of a promisor pack,
> > * and thus we cannot skip the full connectivity check.
> > */
> > - return 0;
> > -
> > -promisor_pack_found:
> > - ;
> > + if (err > 0)
> > + return 0;
>
> And this does.
>
> I may be misreading the patch, but as we return 0 from here, do we
> cause the caller to fall back to full connectivity check? The
> caller, check_connected(), sees a zero returned from here.
You're right, this is a result of the refactor. Previously we had it
like this:
err = odb_for_each_object_ext(the_repository->objects,
NULL, promised_object_cb,
NULL, &opts);
if (err < 0)
break;
if (err > 0) {
err = 0;
continue;
}
But that made us correctly skip to the next object. Now though we have
to check for `if (!err) return 0;` in the refactored code. Makes me
wonder whether the logic would be easier to follow like this:
diff --git a/connected.c b/connected.c
index b557ff5db9..b5a9b0543d 100644
--- a/connected.c
+++ b/connected.c
@@ -13,8 +13,10 @@
static int promised_object_cb(const struct object_id *oid UNUSED,
struct object_info *oi UNUSED,
- void *payload UNUSED)
+ void *payload)
{
+ bool *found = payload;
+ *found = true;
return 1;
}
@@ -45,11 +47,13 @@ static int check_connected_promisor(oid_iterate_fn fn,
odb_reprepare(the_repository->objects);
do {
+ bool found = false;
+
opts.prefix = *oid;
err = odb_for_each_object_ext(the_repository->objects,
NULL, promised_object_cb,
- NULL, &opts);
+ &found, &opts);
if (err < 0)
return err;
@@ -57,7 +61,7 @@ static int check_connected_promisor(oid_iterate_fn fn,
* We have found an object that is not part of a promisor pack,
* and thus we cannot skip the full connectivity check.
*/
- if (err > 0)
+ if (!found)
return 0;
} while ((*oid = fn(cb_data)) != NULL);
It's also a bit concerning that this doesn't cause any tests to fail.
I'll try to figure out whether I can add one.
Thanks!
Patrick
^ permalink raw reply related
* Re: [PATCH v2 2/4] odb/source-packed: support flags when iterating an object prefix
From: Patrick Steinhardt @ 2026-06-25 5:52 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Junio C Hamano, Christian Couder
In-Reply-To: <CAP8UFD1sJNJbAAu9ZUanB8gJV-Vb64pLVkNULm3onSFZirdKxA@mail.gmail.com>
On Wed, Jun 24, 2026 at 07:02:48PM +0200, Christian Couder wrote:
> On Wed, Jun 24, 2026 at 12:37 PM Patrick Steinhardt <ps@pks.im> wrote:
> > diff --git a/odb/source-packed.c b/odb/source-packed.c
> > index 3afc4bf01f..6f31f0ff94 100644
> > --- a/odb/source-packed.c
> > +++ b/odb/source-packed.c
> > @@ -171,6 +172,20 @@ static int for_each_prefixed_object_in_midx(
> > const struct object_id *current = NULL;
> > struct object_id oid;
> >
> > + if (opts->flags) {
> > + uint32_t pack_id = nth_midxed_pack_int_id(m, i);
> > + struct packed_git *pack;
> > +
> > + if (prepare_midx_pack(m, pack_id)) {
> > + pack_errors = true;
> > + continue;
> > + }
> > +
> > + pack = nth_midxed_pack(m, pack_id);
> > + if (should_exclude_pack(pack, opts->flags))
> > + continue;
> > + }
> > +
> > current = nth_midxed_object_oid(&oid, m, i);
> >
> > if (!match_hash(len, opts->prefix->hash, current->hash))
>
> It looks like this is:
>
> if (!match_hash(len, opts->prefix->hash, current->hash))
> break;
>
> and I wonder if the `if (opts->flags) { ... }` block would be better
> after that prefix check rather than before it.
>
> Putting it after the prefix check would make sure we don't continue
> when the prefix doesn't match.
Hm, that's a good point indeed. Will adapt, thanks!
Patrick
^ permalink raw reply
* Re: [PATCH v2 2/2] push: suggest <remote> <branch> for a slash slip
From: Junio C Hamano @ 2026-06-25 3:36 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget; +Cc: git, Harald Nordgren
In-Reply-To: <xmqqa4sjh85o.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
> "Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
>> diff --git a/t/t5529-push-errors.sh b/t/t5529-push-errors.sh
>> index 80b06a0cd2..cfb294305d 100755
>> --- a/t/t5529-push-errors.sh
>> +++ b/t/t5529-push-errors.sh
>> @@ -54,6 +54,37 @@ test_expect_success 'detect empty remote with targeted refspec' '
>> grep "fatal: bad repository ${SQ}${SQ}" stderr
>> '
> t5529-push-errors.sh:59: error: bare grep outside pipeline (use test_grep)
> t5529-push-errors.sh:60: error: bare grep outside pipeline (use test_grep)
> t5529-push-errors.sh:62: error: bare grep outside pipeline (use test_grep)
> t5529-push-errors.sh:67: error: bare grep outside pipeline (use test_grep)
> t5529-push-errors.sh:72: error: bare grep outside pipeline (use test_grep)
> t5529-push-errors.sh:77: error: bare grep outside pipeline (use test_grep)
> t5529-push-errors.sh:84: error: bare grep outside pipeline (use test_grep)
I've queued this squashable? fix on top of the branch before merging
the result to 'seen' for tonight's push-out.
Thanks.
--- >8 ---
Subject: [PATCH] SQUASH??? use test_grep
---
t/t5529-push-errors.sh | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/t/t5529-push-errors.sh b/t/t5529-push-errors.sh
index cfb294305d..2294645902 100755
--- a/t/t5529-push-errors.sh
+++ b/t/t5529-push-errors.sh
@@ -56,32 +56,32 @@ test_expect_success 'detect empty remote with targeted refspec' '
test_expect_success 'suggest <remote> <branch> for a <remote>/<branch> slip' '
test_must_fail git push origin/main 2>stderr &&
- grep "${SQ}origin/main${SQ} is not a valid push target" stderr &&
- grep "hint: Did you mean to use: git push origin main?" stderr &&
+ test_grep "${SQ}origin/main${SQ} is not a valid push target" stderr &&
+ test_grep "hint: Did you mean to use: git push origin main?" stderr &&
test_must_fail git -c advice.pushRepoLooksLikeRef=false push origin/main 2>stderr &&
- ! grep "Did you mean" stderr
+ test_grep ! "Did you mean" stderr
'
test_expect_success 'suggest <remote> <branch> when the branch has slashes' '
test_must_fail git push origin/feature/x 2>stderr &&
- grep "hint: Did you mean to use: git push origin feature/x?" stderr
+ test_grep "hint: Did you mean to use: git push origin feature/x?" stderr
'
test_expect_success 'no suggestion when prefix is not a configured remote' '
test_must_fail git push not-a-remote/main 2>stderr &&
- ! grep "Did you mean" stderr
+ test_grep ! "Did you mean" stderr
'
test_expect_success 'no suggestion for a trailing slash with no branch' '
test_must_fail git push origin/ 2>stderr &&
- ! grep "Did you mean" stderr
+ test_grep ! "Did you mean" stderr
'
test_expect_success 'no suggestion when the argument is an existing path' '
test_when_finished "rm -rf origin" &&
git init --bare origin/main &&
git push origin/main HEAD:refs/heads/pushed 2>stderr &&
- ! grep "Did you mean" stderr &&
+ test_grep ! "Did you mean" stderr &&
git -C origin/main rev-parse --verify refs/heads/pushed
'
--
2.55.0-rc2-165-g3249676ba5
^ permalink raw reply related
* Re: [PATCH v14 2/2] checkout: extend --track with a "fetch" mode to refresh start-point
From: Ben Knoble @ 2026-06-25 1:17 UTC (permalink / raw)
To: Junio C Hamano
Cc: Harald Nordgren, phillip.wood, Harald Nordgren via GitGitGadget,
git, Ramsay Jones, Kristoffer Haugsbakk, Marc Branchaud
In-Reply-To: <xmqq5x37h6fj.fsf@gitster.g>
> Le 24 juin 2026 à 19:20, Junio C Hamano <gitster@pobox.com> a écrit :
>
> Harald Nordgren <haraldnordgren@gmail.com> writes:
>
>> Ok, let's focus on the need for the feature before talking code:
>>
>> In an active project, forking from "origin/master" without refreshing
>> first often has consequences: you start work that has already been
>> done, or you build on an old version of the code which causes big
>> conflicts only later when you pull. The fix is simple ...
>
> The above only argues that contributors should not start work on top
> of a stale codebase without looking at reasonably recent codebase.
>
> I am not sure if automated fetch immediately before forking to start
> work will be a good fix for that, especially if the fork of a new
> branch is done blindly _without_ looking at what the updated
> upstream contains.
>
>> ... ("git fetch
>> origin master && git checkout -b topic origin/master"), but it is
>> still a mouthful. Other tools exist because this is annoying enough
>> that people automate it.
>
> And to actually look at the recent codebase, one would probably need
>
> git fetch
> git log [-p] ..origin -- your-area-of-interest/
> ... other inspection of the recent changes to refresh your
> ... understanding of the base code comes here
> git checkout -b topic origin
>
> or something like that. Wouldn't folding the first and the third
> step into one operation encourage omitting the second step? In a
> sense, having a tool to let people blindly fetch and fork without
> looking at what changed recently (i.e., they had a reason to think
> that what they had was stale, so has a fetch actually resolved that
> staleness? what new things did the fetch bring in?) may encourage
> a bad workflow.
I think I remain overall ambivalent, but as anecdata: when I’m working on my employer’scode, it is the default (90%+?) for folks to omit step 2 and have the kind of blind fetch + branch that this would facilitate.
I myself do this when I’m reasonably sure the other changes can’t be of interest (common), or when I suspect the change I’m going to start on will conflict with recent changes I haven’t fetched. At other times I’m more interested in step 2, but generally I omit it at work.
Now, as to why: I spend a lot more time reviewing PRs at work (and making sure they merge quickly when they are in the right direction), and so I’m usually fairly confident of what a fetch is going to bring! [I also fetch several times a day to keep up to date locally, to facilitate various maintenance, admin, and archaeology tasks.] Contrast with distributed open source projects, where I might not have fetched for weeks and can’t predict what might fall out (let alone how it might it interact with local WIP).
So « bad workflow » I agree with, but am plenty guilty of :)
To wrap up, I wonder if the convenience of this proposal is especially aimed at folks like my corporate environment (where « build near the tip and integrate quickly » is the norm), but less than useful for those same folks in a different situation?
(OTOH, I suppose I might use something similar when starting a new topic branch from Git’s master branch, since there’s probably no harm in working on a recent copy of master unless I already have older code that needs updated?)
> An obvious complaint against "update and always inspect and
> understand" would be "it would slow us down!", but that is why
> projects encourage forking your topic at a well known release tags,
> not from a random "tip of the tree of the day".
>
> I think most of the above has already been communicated earlier in
> discussions before we got to v14, but I may be wrong. Are there any
> new arguments in support of the feature?
^ permalink raw reply
* Re: [PATCH v14 2/2] checkout: extend --track with a "fetch" mode to refresh start-point
From: Junio C Hamano @ 2026-06-24 23:20 UTC (permalink / raw)
To: Harald Nordgren
Cc: phillip.wood, Harald Nordgren via GitGitGadget, git, Ramsay Jones,
D. Ben Knoble, Kristoffer Haugsbakk, Marc Branchaud
In-Reply-To: <CAHwyqnWwyPHiaOW+rz-Z9ZvRf=OjXWw2T+rB3cSsxXWXkeRm=Q@mail.gmail.com>
Harald Nordgren <haraldnordgren@gmail.com> writes:
> Ok, let's focus on the need for the feature before talking code:
>
> In an active project, forking from "origin/master" without refreshing
> first often has consequences: you start work that has already been
> done, or you build on an old version of the code which causes big
> conflicts only later when you pull. The fix is simple ...
The above only argues that contributors should not start work on top
of a stale codebase without looking at reasonably recent codebase.
I am not sure if automated fetch immediately before forking to start
work will be a good fix for that, especially if the fork of a new
branch is done blindly _without_ looking at what the updated
upstream contains.
> ... ("git fetch
> origin master && git checkout -b topic origin/master"), but it is
> still a mouthful. Other tools exist because this is annoying enough
> that people automate it.
And to actually look at the recent codebase, one would probably need
git fetch
git log [-p] ..origin -- your-area-of-interest/
... other inspection of the recent changes to refresh your
... understanding of the base code comes here
git checkout -b topic origin
or something like that. Wouldn't folding the first and the third
step into one operation encourage omitting the second step? In a
sense, having a tool to let people blindly fetch and fork without
looking at what changed recently (i.e., they had a reason to think
that what they had was stale, so has a fetch actually resolved that
staleness? what new things did the fetch bring in?) may encourage
a bad workflow.
An obvious complaint against "update and always inspect and
understand" would be "it would slow us down!", but that is why
projects encourage forking your topic at a well known release tags,
not from a random "tip of the tree of the day".
I think most of the above has already been communicated earlier in
discussions before we got to v14, but I may be wrong. Are there any
new arguments in support of the feature?
^ permalink raw reply
* Re: [PATCH v2 2/2] push: suggest <remote> <branch> for a slash slip
From: Junio C Hamano @ 2026-06-24 22:42 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget; +Cc: git, Harald Nordgren
In-Reply-To: <49de5a925de506ed9a141eb72927b2548b73af22.1782338114.git.gitgitgadget@gmail.com>
"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> diff --git a/t/t5529-push-errors.sh b/t/t5529-push-errors.sh
> index 80b06a0cd2..cfb294305d 100755
> --- a/t/t5529-push-errors.sh
> +++ b/t/t5529-push-errors.sh
> @@ -54,6 +54,37 @@ test_expect_success 'detect empty remote with targeted refspec' '
> grep "fatal: bad repository ${SQ}${SQ}" stderr
> '
>
> +test_expect_success 'suggest <remote> <branch> for a <remote>/<branch> slip' '
> + test_must_fail git push origin/main 2>stderr &&
> + grep "${SQ}origin/main${SQ} is not a valid push target" stderr &&
> + grep "hint: Did you mean to use: git push origin main?" stderr &&
> + test_must_fail git -c advice.pushRepoLooksLikeRef=false push origin/main 2>stderr &&
> + ! grep "Did you mean" stderr
> +'
> +
> +test_expect_success 'suggest <remote> <branch> when the branch has slashes' '
> + test_must_fail git push origin/feature/x 2>stderr &&
> + grep "hint: Did you mean to use: git push origin feature/x?" stderr
> +'
> +
> +test_expect_success 'no suggestion when prefix is not a configured remote' '
> + test_must_fail git push not-a-remote/main 2>stderr &&
> + ! grep "Did you mean" stderr
> +'
> +
> +test_expect_success 'no suggestion for a trailing slash with no branch' '
> + test_must_fail git push origin/ 2>stderr &&
> + ! grep "Did you mean" stderr
> +'
t5529-push-errors.sh:59: error: bare grep outside pipeline (use test_grep)
t5529-push-errors.sh:60: error: bare grep outside pipeline (use test_grep)
t5529-push-errors.sh:62: error: bare grep outside pipeline (use test_grep)
t5529-push-errors.sh:67: error: bare grep outside pipeline (use test_grep)
t5529-push-errors.sh:72: error: bare grep outside pipeline (use test_grep)
t5529-push-errors.sh:77: error: bare grep outside pipeline (use test_grep)
t5529-push-errors.sh:84: error: bare grep outside pipeline (use test_grep)
^ permalink raw reply
* Re: [PATCH v2 1/2] branch: suggest <remote>/<branch> on upstream slip
From: Junio C Hamano @ 2026-06-24 22:33 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget; +Cc: git, Harald Nordgren
In-Reply-To: <11bcecebf43797a889f08e79401370f43b2917a8.1782338114.git.gitgitgadget@gmail.com>
"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> When setting the upstream of the current branch to the 'main' branch
> of the remote 'origin', i.e.,
>
> $ git branch --set-upstream-to origin/main
>
> it is easy to mistakenly write
>
> $ git branch --set-upstream-to origin main
>
> That is parsed as a request to set the upstream of the local branch
> 'main' to 'origin'. When 'main' does not exist, the command dies
> with:
>
> fatal: branch 'main' does not exist
>
> pointing at a branch the user never meant to name.
It is more complete to add the other case here, something along the
lines of ...
And then when 'main' does exist, the command would die with
fatal: the requested upstream branch 'origin' does not exist
leaving the user equally confused.
... no? In any case, this is much more nicely described than the
previous round. I see no room for confusion.
> When the operated-on branch is missing and '<remote>/<branch>' names
> a real remote-tracking ref, suggest the intended form:
>
> $ git branch --set-upstream-to=origin/main
>
> The suggestion is gated on '<remote>/<branch>' existing so it only
> appears when a slipped slash is the likely explanation.
Makes sense.
Do we want to do anything on a case where the operated-on branch
does exist but '<remote>' is not a name suitable for an upstream,
but '<remote>/<branch>' is?
> diff --git a/builtin/branch.c b/builtin/branch.c
> index 1572a4f9ef..cefc4519a7 100644
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -706,6 +706,29 @@ static int edit_branch_description(const char *branch_name)
> return 0;
> }
>
> +static void die_if_upstream_looks_like_remote(const char *new_upstream, const char *branch_name)
> +{
> + struct strbuf remote_ref = STRBUF_INIT;
> + int code;
> +
> + if (strchr(new_upstream, '/') ||
> + !remote_is_configured(remote_get(new_upstream), 0))
> + return;
> +
> + strbuf_addf(&remote_ref, "refs/remotes/%s/%s", new_upstream, branch_name);
> + if (!refs_ref_exists(get_main_ref_store(the_repository), remote_ref.buf)) {
> + strbuf_release(&remote_ref);
> + return;
> + }
> +
> + code = die_message(_("--set-upstream-to takes a single <remote>/<branch> argument"));
> + advise_if_enabled(ADVICE_SET_UPSTREAM_FAILURE,
> + _("Did you mean to use: git branch --set-upstream-to=%s/%s?"),
> + new_upstream, branch_name);
Do we still need the _if_enabled() thing here? Isn't the caller
gated with the same condition in this version?
> + strbuf_release(&remote_ref);
> + exit(code);
> +}
> +
> int cmd_branch(int argc,
> const char **argv,
> const char *prefix,
> @@ -957,6 +980,9 @@ int cmd_branch(int argc,
> if (!refs_ref_exists(get_main_ref_store(the_repository), branch->refname)) {
> if (!argc || branch_checked_out(branch->refname))
> die(_("no commit on branch '%s' yet"), branch->name);
> + if (argc == 1 &&
> + advice_enabled(ADVICE_SET_UPSTREAM_FAILURE))
> + die_if_upstream_looks_like_remote(new_upstream, argv[0]);
> die(_("branch '%s' does not exist"), branch->name);
> }
This is totally a tangent, but has anybody noticed that the web
interface to the lore archive seems to be constipated? I am reading
over nntp and subscribers are reading from their inbox, so no real
harm done, but from time to time we get reminded how heavily our
development process relies on the services like kernel.org and feel
grateful to have them.
^ permalink raw reply
* Re: [PATCH v5 10/11] refs/reftable: lazy-load configuration to fix chicken-and-egg
From: Justin Tobler @ 2026-06-24 22:18 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Karthik Nayak, Jeff King
In-Reply-To: <20260622-b4-pks-refs-avoid-chdir-notify-reparent-v5-10-018475013dbc@pks.im>
On 26/06/22 10:28AM, Patrick Steinhardt wrote:
> Same as with the "files" backend, the "reftable" backend also has a
> chicken-and-egg problem with "onbranch" conditions. Fix this issue the
> same as we did with the "files" backend by lazy-loading configuration.
Makes sense.
> Now that both the "files" and the "reftable" backend handle this
> properly, add a generic test to t1400 that verifies that the user can
> configure "core.logAllRefUpdates" via an "onbranch" condition. This is
> mostly a nonsensical thing to do in the first place, but it serves as a
> good sanity chekc.
s/chekc/check
> Note that we had to move `should_write_log()` around so that it can
> access the new `reftable_be_write_options()` function.
>
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
> refs/reftable-backend.c | 146 ++++++++++++++++++++++----------------
> t/t0613-reftable-write-options.sh | 19 +++++
> t/t1400-update-ref.sh | 12 ++++
> 3 files changed, 116 insertions(+), 61 deletions(-)
>
> diff --git a/refs/reftable-backend.c b/refs/reftable-backend.c
> index 608d71cf10..d74131a5ae 100644
> --- a/refs/reftable-backend.c
> +++ b/refs/reftable-backend.c
> @@ -141,10 +141,21 @@ struct reftable_ref_store {
> */
> struct strmap worktree_backends;
> struct reftable_stack_options stack_options;
> - struct reftable_write_options write_options;
> +
> + /*
> + * Options used when writing to or compacting the reftable stacks.
> + * These are parsed from the configuration lazily on first use via
> + * `reftable_be_write_options()` so that we don't have to access the
> + * configuration when initializing the ref store. Do not access these
> + * fields directly, but use the accessor instead.
> + */
> + struct reftable_be_write_options {
> + struct reftable_write_options opts;
> + enum log_refs_config log_all_ref_updates;
Any reason in particular that `log_all_ref_updates` is the only option
outside of `struct reftlable_write_options` here? Isn't it also only
used during writes?
-Justin
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox