* [PATCH v2 2/2] push: suggest <remote> <branch> for a slash slip
From: Harald Nordgren via GitGitGadget @ 2026-06-24 21:55 UTC (permalink / raw)
To: git; +Cc: Harald Nordgren, Harald Nordgren
In-Reply-To: <pull.2331.v2.git.git.1782338114.gitgitgadget@gmail.com>
From: Harald Nordgren <haraldnordgren@gmail.com>
When pushing the 'main' branch to the remote 'origin', i.e.,
$ git push origin main
it is easy to mistakenly write
$ git push origin/main
That is parsed as the repository to push to, and since 'origin/main'
is neither a configured remote nor a path it dies with:
fatal: 'origin/main' does not appear to be a git repository
Often 'origin/main' does not exist as a repository, so the command
fails without doing any harm, but it gives no hint that a space was
meant instead of a slash and can leave the user puzzled.
When the argument is not an existing path or configured remote but
its part before the first slash names one, suggest the intended
'<remote> <branch>' form:
$ git push origin main
The suggestion is shown as advice so it can be silenced with
advice.pushRepoLooksLikeRef.
Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
---
Documentation/config/advice.adoc | 5 +++++
advice.c | 1 +
advice.h | 1 +
builtin/push.c | 31 ++++++++++++++++++++++++++++++-
t/t5529-push-errors.sh | 31 +++++++++++++++++++++++++++++++
5 files changed, 68 insertions(+), 1 deletion(-)
diff --git a/Documentation/config/advice.adoc b/Documentation/config/advice.adoc
index 257db58918..fa77a5110e 100644
--- a/Documentation/config/advice.adoc
+++ b/Documentation/config/advice.adoc
@@ -90,6 +90,11 @@ all advice messages.
Shown when linkgit:git-push[1] rejects a forced update of
a branch when its remote-tracking ref has updates that we
do not have locally.
+ pushRepoLooksLikeRef::
+ Shown when the repository given to linkgit:git-push[1] is not
+ a configured remote but looks like a `<remote>/<branch>` ref,
+ suggesting that the remote and branch be given as separate
+ arguments.
pushUnqualifiedRefname::
Shown when linkgit:git-push[1] gives up trying to
guess based on the source and destination refs what
diff --git a/advice.c b/advice.c
index 0018501b7b..63bf8b0c5f 100644
--- a/advice.c
+++ b/advice.c
@@ -69,6 +69,7 @@ static struct {
[ADVICE_PUSH_NON_FF_CURRENT] = { "pushNonFFCurrent" },
[ADVICE_PUSH_NON_FF_MATCHING] = { "pushNonFFMatching" },
[ADVICE_PUSH_REF_NEEDS_UPDATE] = { "pushRefNeedsUpdate" },
+ [ADVICE_PUSH_REPO_LOOKS_LIKE_REF] = { "pushRepoLooksLikeRef" },
[ADVICE_PUSH_UNQUALIFIED_REF_NAME] = { "pushUnqualifiedRefName" },
[ADVICE_PUSH_UPDATE_REJECTED] = { "pushUpdateRejected" },
[ADVICE_PUSH_UPDATE_REJECTED_ALIAS] = { "pushNonFastForward" }, /* backwards compatibility */
diff --git a/advice.h b/advice.h
index 8def280688..66f6cd6a77 100644
--- a/advice.h
+++ b/advice.h
@@ -36,6 +36,7 @@ enum advice_type {
ADVICE_PUSH_NON_FF_CURRENT,
ADVICE_PUSH_NON_FF_MATCHING,
ADVICE_PUSH_REF_NEEDS_UPDATE,
+ ADVICE_PUSH_REPO_LOOKS_LIKE_REF,
ADVICE_PUSH_UNQUALIFIED_REF_NAME,
ADVICE_PUSH_UPDATE_REJECTED,
ADVICE_PUSH_UPDATE_REJECTED_ALIAS,
diff --git a/builtin/push.c b/builtin/push.c
index 6021b71d66..255556b44d 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -8,6 +8,7 @@
#include "advice.h"
#include "branch.h"
#include "config.h"
+#include "dir.h"
#include "environment.h"
#include "gettext.h"
#include "hex.h"
@@ -662,6 +663,29 @@ static int push_multiple(struct string_list *list,
return result;
}
+static void die_if_repo_looks_like_ref(const char *repo)
+{
+ const char *slash = strchr(repo, '/');
+ struct strbuf name = STRBUF_INIT;
+ int code;
+
+ if (!slash || !slash[1] || file_exists(repo))
+ return;
+
+ strbuf_add(&name, repo, slash - repo);
+ if (!remote_is_configured(remote_get(name.buf), 0)) {
+ strbuf_release(&name);
+ return;
+ }
+
+ code = die_message(_("'%s' is not a valid push target"), repo);
+ advise_if_enabled(ADVICE_PUSH_REPO_LOOKS_LIKE_REF,
+ _("Did you mean to use: git push %s %s?"),
+ name.buf, slash + 1);
+ strbuf_release(&name);
+ exit(code);
+}
+
int cmd_push(int argc,
const char **argv,
const char *prefix,
@@ -744,6 +768,11 @@ int cmd_push(int argc,
if (repo) {
if (!add_remote_or_group(repo, &remote_group)) {
+ struct remote *r;
+
+ if (advice_enabled(ADVICE_PUSH_REPO_LOOKS_LIKE_REF))
+ die_if_repo_looks_like_ref(repo);
+
/*
* Not a configured remote name or group name.
* Try treating it as a direct URL or path, e.g.
@@ -753,7 +782,7 @@ int cmd_push(int argc,
* from the URL so the loop below can handle it
* identically to a named remote.
*/
- struct remote *r = pushremote_get(repo);
+ r = pushremote_get(repo);
if (!r)
die(_("bad repository '%s'"), repo);
string_list_append(&remote_group, r->name);
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
+'
+
+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 &&
+ git -C origin/main rev-parse --verify refs/heads/pushed
+'
+
test_expect_success 'detect ambiguous refs early' '
git branch foo &&
git tag foo &&
--
gitgitgadget
^ permalink raw reply related
* [PATCH v18 7/7] branch: add --dry-run for --delete-merged
From: Harald Nordgren via GitGitGadget @ 2026-06-24 21:55 UTC (permalink / raw)
To: git
Cc: Kristoffer Haugsbakk, Johannes Sixt, Phillip Wood,
Harald Nordgren, Harald Nordgren
In-Reply-To: <pull.2285.v18.git.git.1782338106.gitgitgadget@gmail.com>
From: Harald Nordgren <haraldnordgren@gmail.com>
With --dry-run, --delete-merged prints the local branches it would
delete, one "Would delete branch <name>" line each, and exits
without touching any ref. The same filtering applies, so the output
is exactly the set that the real run would delete.
--dry-run is only meaningful together with --delete-merged and is
rejected otherwise.
Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
---
Documentation/git-branch.adoc | 8 +++++++-
builtin/branch.c | 22 +++++++++++++++++++---
t/t3200-branch.sh | 11 ++++++++++-
3 files changed, 36 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-branch.adoc b/Documentation/git-branch.adoc
index d482cded3d..00d6192e6a 100644
--- a/Documentation/git-branch.adoc
+++ b/Documentation/git-branch.adoc
@@ -25,7 +25,7 @@ git branch (-m|-M) [<old-branch>] <new-branch>
git branch (-c|-C) [<old-branch>] <new-branch>
git branch (-d|-D) [-r] <branch-name>...
git branch --edit-description [<branch-name>]
-git branch --delete-merged <branch>...
+git branch [--dry-run] --delete-merged <branch>...
DESCRIPTION
-----------
@@ -231,6 +231,12 @@ kept, so a branch is never deleted out from under one stacked on top
of it. If that kept branch in turn tracks a branch that is being
deleted, its now-stale upstream configuration is cleared.
+`--dry-run`::
+ With `--delete-merged`, print which branches would be
+ deleted and exit without touching any ref. Useful for
+ sanity-checking a wide pattern like `'origin/*'` before
+ committing to the deletion.
+
`-v`::
`-vv`::
`--verbose`::
diff --git a/builtin/branch.c b/builtin/branch.c
index bce85cb52e..e7763437fb 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -199,6 +199,7 @@ enum delete_branch_flags {
DELETE_BRANCH_QUIET = (1 << 1),
DELETE_BRANCH_SKIP_UNMERGED = (1 << 2),
DELETE_BRANCH_NO_HEAD_FALLBACK = (1 << 3),
+ DELETE_BRANCH_DRY_RUN = (1 << 4),
};
static int check_branch_commit(const char *branchname, const char *refname,
@@ -248,6 +249,7 @@ static int delete_branches(int argc, const char **argv, int kinds,
bool quiet = flags & DELETE_BRANCH_QUIET;
bool skip_unmerged = flags & DELETE_BRANCH_SKIP_UNMERGED;
bool no_head_fallback = flags & DELETE_BRANCH_NO_HEAD_FALLBACK;
+ bool dry_run = flags & DELETE_BRANCH_DRY_RUN;
struct strbuf bname = STRBUF_INIT;
enum interpret_branch_kind allowed_interpret;
struct string_list refs_to_delete = STRING_LIST_INIT_DUP;
@@ -346,13 +348,20 @@ static int delete_branches(int argc, const char **argv, int kinds,
free(target);
}
- if (refs_delete_refs(get_main_ref_store(the_repository), NULL, &refs_to_delete, REF_NO_DEREF))
+ if (!dry_run &&
+ refs_delete_refs(get_main_ref_store(the_repository), NULL, &refs_to_delete, REF_NO_DEREF))
ret = 1;
for_each_string_list_item(item, &refs_to_delete) {
char *describe_ref = item->util;
char *name = item->string;
- if (!refs_ref_exists(get_main_ref_store(the_repository), name)) {
+ if (dry_run) {
+ if (!quiet)
+ printf(remote_branch
+ ? _("Would delete remote-tracking branch %s (was %s).\n")
+ : _("Would delete branch %s (was %s).\n"),
+ name + branch_name_pos, describe_ref);
+ } else if (!refs_ref_exists(get_main_ref_store(the_repository), name)) {
char *refname = name + branch_name_pos;
if (!quiet)
printf(remote_branch
@@ -897,6 +906,7 @@ int cmd_branch(int argc,
int delete = 0, rename = 0, copy = 0, list = 0,
unset_upstream = 0, show_current = 0, edit_description = 0;
int delete_merged = 0;
+ int dry_run = 0;
const char *new_upstream = NULL;
int noncreate_actions = 0;
/* possible options */
@@ -952,6 +962,8 @@ int cmd_branch(int argc,
N_("edit the description for the branch")),
OPT_BOOL(0, "delete-merged", &delete_merged,
N_("delete local branches whose upstream matches <branch> and are merged")),
+ OPT_BOOL(0, "dry-run", &dry_run,
+ N_("with --delete-merged, only print which branches would be deleted")),
OPT__FORCE(&force, N_("force creation, move/rename, deletion"), PARSE_OPT_NOCOMPLETE),
OPT_MERGED(&filter, N_("print only branches that are merged")),
OPT_NO_MERGED(&filter, N_("print only branches that are not merged")),
@@ -1014,6 +1026,9 @@ int cmd_branch(int argc,
if (noncreate_actions > 1)
usage_with_options(builtin_branch_usage, options);
+ if (dry_run && !delete_merged)
+ die(_("--dry-run requires --delete-merged"));
+
if (recurse_submodules_explicit) {
if (!submodule_propagate_branches)
die(_("branch with --recurse-submodules can only be used if submodule.propagateBranches is enabled"));
@@ -1054,7 +1069,8 @@ int cmd_branch(int argc,
goto out;
} else if (delete_merged) {
ret = delete_merged_branches(argc, argv,
- quiet ? DELETE_BRANCH_QUIET : 0);
+ (quiet ? DELETE_BRANCH_QUIET : 0) |
+ (dry_run ? DELETE_BRANCH_DRY_RUN : 0));
goto out;
} else if (show_current) {
print_current_branch_name();
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index b7595610d9..cddcde341d 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -1892,8 +1892,12 @@ test_expect_success '--delete-merged deletes merged branches and spares the rest
) &&
sha=$(git -C repo rev-parse --short merged) &&
- git -C repo branch --delete-merged origin/next >actual 2>&1 &&
+ git -C repo branch --dry-run --delete-merged origin/next >actual 2>&1 &&
+ echo "Would delete branch merged (was $sha)." >expect &&
+ test_cmp expect actual &&
+ git -C repo rev-parse --verify refs/heads/merged &&
+ git -C repo branch --delete-merged origin/next >actual 2>&1 &&
echo "Deleted branch merged (was $sha)." >expect &&
test_cmp expect actual &&
git -C repo for-each-ref --format="%(refname:short)" refs/heads/ >actual &&
@@ -2050,4 +2054,9 @@ test_expect_success "branch -d still deletes a deleteMerged=false branch" '
test_must_fail git -C repo rev-parse --verify refs/heads/kept
'
+test_expect_success '--dry-run without --delete-merged is rejected' '
+ test_must_fail git -C forked branch --dry-run 2>err &&
+ test_grep "requires --delete-merged" err
+'
+
test_done
--
gitgitgadget
^ permalink raw reply related
* [PATCH v18 5/7] branch: add --delete-merged <branch>
From: Harald Nordgren via GitGitGadget @ 2026-06-24 21:55 UTC (permalink / raw)
To: git
Cc: Kristoffer Haugsbakk, Johannes Sixt, Phillip Wood,
Harald Nordgren, Harald Nordgren
In-Reply-To: <pull.2285.v18.git.git.1782338106.gitgitgadget@gmail.com>
From: Harald Nordgren <haraldnordgren@gmail.com>
git branch --delete-merged <branch>...
deletes the local branches that "--forked <branch>" would list,
keeping only those whose tip is reachable from their configured
upstream. The work has already landed on the upstream they track,
so the local copy is no longer needed.
A branch is not deleted when:
* it is checked out in any worktree
* its upstream remote-tracking branch no longer exists, since a
missing upstream is not by itself a sign of integration
* its push destination equals its upstream (<branch>@{push} is
the same as <branch>@{upstream}), such as a local "main" that
tracks and pushes to "origin/main". Right after a pull it just
looks "fully merged", so it is kept. Only branches that push
somewhere other than their upstream, typically topics in a fork
workflow, are candidates.
A branch whose work is not yet merged into its upstream is silently
skipped, so one unmerged topic does not abort the whole sweep.
A branch that another, surviving branch tracks as its upstream is
also kept, so a branch is never deleted out from under one stacked
on top of it. Such a kept branch is itself merged, so when its own
upstream is being deleted, clear its now-stale upstream config.
Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
---
Documentation/git-branch.adoc | 29 ++++++
builtin/branch.c | 147 ++++++++++++++++++++++++++-
t/t3200-branch.sh | 185 ++++++++++++++++++++++++++++++++++
3 files changed, 359 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-branch.adoc b/Documentation/git-branch.adoc
index b0d66a6deb..66b1c87c55 100644
--- a/Documentation/git-branch.adoc
+++ b/Documentation/git-branch.adoc
@@ -25,6 +25,7 @@ git branch (-m|-M) [<old-branch>] <new-branch>
git branch (-c|-C) [<old-branch>] <new-branch>
git branch (-d|-D) [-r] <branch-name>...
git branch --edit-description [<branch-name>]
+git branch --delete-merged <branch>...
DESCRIPTION
-----------
@@ -201,6 +202,34 @@ This option is only applicable in non-verbose mode.
Print the name of the current branch. In detached `HEAD` state,
nothing is printed.
+`--delete-merged <branch>...`::
+ Delete the local branches that `--forked` would list for the
+ given _<branch>_ arguments, but only those whose tip is
+ reachable from their configured upstream. In other words, the
+ work on the branch has already landed on the upstream it
+ tracks, so the local copy is no longer needed. Several
+ _<branch>_ patterns may be given, e.g. `git branch
+ --delete-merged origin/main 'feature*'`.
++
+A branch is not deleted when:
++
+--
+* its upstream remote-tracking branch no longer exists,
+* it is checked out in any worktree, or
+* its push destination (`<branch>@{push}`) equals its upstream
+ (`<branch>@{upstream}`), so it cannot be distinguished from a
+ branch that just looks "fully merged" right after a pull.
+--
++
+A branch whose work has not yet been merged into its upstream is
+silently skipped. Delete it with `git branch -D` if you want to
+remove it anyway.
++
+A branch that another, surviving branch tracks as its upstream is
+kept, so a branch is never deleted out from under one stacked on top
+of it. If that kept branch in turn tracks a branch that is being
+deleted, its now-stale upstream configuration is cleared.
+
`-v`::
`-vv`::
`--verbose`::
diff --git a/builtin/branch.c b/builtin/branch.c
index 01c1f64c73..d12a2f57ea 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -21,6 +21,7 @@
#include "branch.h"
#include "path.h"
#include "string-list.h"
+#include "strmap.h"
#include "column.h"
#include "utf8.h"
#include "ref-filter.h"
@@ -38,6 +39,7 @@ static const char * const builtin_branch_usage[] = {
N_("git branch [<options>] (-c | -C) [<old-branch>] <new-branch>"),
N_("git branch [<options>] [-r | -a] [--points-at]"),
N_("git branch [<options>] [-r | -a] [--format]"),
+ N_("git branch [<options>] --delete-merged <branch>..."),
NULL
};
@@ -705,6 +707,139 @@ static int parse_opt_forked(const struct option *opt, const char *arg, int unset
return 0;
}
+struct spare_data {
+ struct strset *deletable;
+ struct strset *spared;
+};
+
+/*
+ * A surviving branch stacked on a deletion candidate would lose its
+ * upstream, so drop that candidate from the delete set and remember it
+ * in "spared" so its own upstream can be tidied up afterwards.
+ */
+static int spare_stacked_base(const struct reference *ref, void *cb_data)
+{
+ struct spare_data *data = cb_data;
+ struct branch *branch;
+ const char *upstream, *up_short;
+
+ if (strset_contains(data->deletable, ref->name))
+ return 0;
+ branch = branch_get(ref->name);
+ upstream = branch_get_upstream(branch, NULL);
+ if (!upstream || !skip_prefix(upstream, "refs/heads/", &up_short) ||
+ !strset_contains(data->deletable, up_short))
+ return 0;
+
+ strset_remove(data->deletable, up_short);
+ strset_add(data->spared, up_short);
+ return 0;
+}
+
+/*
+ * Keep any branch that a surviving branch tracks as its upstream, so we
+ * never delete a branch out from under one stacked on top of it. Such a
+ * base is itself merged, so when its own upstream is also going away
+ * (no surviving branch tracks it), clear the base's now-stale upstream.
+ */
+static void spare_stacked_bases(struct ref_store *refs, struct strset *deletable)
+{
+ struct strset spared = STRSET_INIT;
+ struct spare_data data = { .deletable = deletable, .spared = &spared };
+ struct strbuf key = STRBUF_INIT;
+ struct hashmap_iter iter;
+ struct strmap_entry *entry;
+
+ refs_for_each_branch_ref(refs, spare_stacked_base, &data);
+
+ strset_for_each_entry(&spared, &iter, entry) {
+ struct branch *branch = branch_get(entry->key);
+ const char *upstream = branch_get_upstream(branch, NULL);
+ const char *up_short;
+
+ if (!upstream || !skip_prefix(upstream, "refs/heads/", &up_short) ||
+ !strset_contains(deletable, up_short))
+ continue;
+
+ strbuf_reset(&key);
+ strbuf_addf(&key, "branch.%s.merge", branch->name);
+ repo_config_set_gently(the_repository, key.buf, NULL);
+ strbuf_reset(&key);
+ strbuf_addf(&key, "branch.%s.remote", branch->name);
+ repo_config_set_gently(the_repository, key.buf, NULL);
+ }
+
+ strbuf_release(&key);
+ strset_clear(&spared);
+}
+
+static int delete_merged_branches(int argc, const char **argv,
+ unsigned int flags)
+{
+ struct ref_store *refs = get_main_ref_store(the_repository);
+ struct ref_filter filter = REF_FILTER_INIT;
+ struct ref_array candidates = { 0 };
+ struct strset deletable = STRSET_INIT;
+ struct strvec to_delete = STRVEC_INIT;
+ struct hashmap_iter iter;
+ struct strmap_entry *entry;
+ int i, ret = 0;
+
+ if (!argc)
+ die(_("--delete-merged requires at least one <branch>"));
+
+ for (i = 0; i < argc; i++)
+ if (ref_filter_forked_add(&filter, argv[i]) < 0)
+ die(_("'%s' is not a valid branch or pattern"), argv[i]);
+
+ filter.kind = FILTER_REFS_BRANCHES;
+ filter_refs(&candidates, &filter, filter.kind);
+
+ for (i = 0; i < candidates.nr; i++) {
+ const char *full_name = candidates.items[i]->refname;
+ const char *short_name;
+ struct branch *branch;
+ const char *upstream, *push;
+
+ if (!skip_prefix(full_name, "refs/heads/", &short_name))
+ BUG("filter returned non-branch ref '%s'", full_name);
+ if (branch_checked_out(full_name))
+ continue;
+
+ branch = branch_get(short_name);
+ upstream = branch_get_upstream(branch, NULL);
+ if (!upstream || !refs_ref_exists(refs, upstream))
+ continue;
+ push = branch_get_push(branch, NULL);
+ if (!push || !strcmp(push, upstream))
+ continue;
+ if (check_branch_commit(short_name, short_name,
+ &candidates.items[i]->objectname, NULL,
+ FILTER_REFS_BRANCHES, DELETE_BRANCH_SKIP_UNMERGED))
+ continue;
+
+ strset_add(&deletable, short_name);
+ }
+
+ spare_stacked_bases(refs, &deletable);
+
+ strset_for_each_entry(&deletable, &iter, entry)
+ strvec_push(&to_delete, entry->key);
+
+ if (to_delete.nr)
+ ret = delete_branches(to_delete.nr, to_delete.v,
+ FILTER_REFS_BRANCHES,
+ DELETE_BRANCH_SKIP_UNMERGED |
+ DELETE_BRANCH_NO_HEAD_FALLBACK |
+ flags);
+
+ strvec_clear(&to_delete);
+ strset_clear(&deletable);
+ ref_array_clear(&candidates);
+ ref_filter_clear(&filter);
+ return ret;
+}
+
static GIT_PATH_FUNC(edit_description, "EDIT_DESCRIPTION")
static int edit_branch_description(const char *branch_name)
@@ -746,6 +881,7 @@ int cmd_branch(int argc,
/* possible actions */
int delete = 0, rename = 0, copy = 0, list = 0,
unset_upstream = 0, show_current = 0, edit_description = 0;
+ int delete_merged = 0;
const char *new_upstream = NULL;
int noncreate_actions = 0;
/* possible options */
@@ -799,6 +935,8 @@ int cmd_branch(int argc,
OPT_BOOL(0, "create-reflog", &reflog, N_("create the branch's reflog")),
OPT_BOOL(0, "edit-description", &edit_description,
N_("edit the description for the branch")),
+ OPT_BOOL(0, "delete-merged", &delete_merged,
+ N_("delete local branches whose upstream matches <branch> and are merged")),
OPT__FORCE(&force, N_("force creation, move/rename, deletion"), PARSE_OPT_NOCOMPLETE),
OPT_MERGED(&filter, N_("print only branches that are merged")),
OPT_NO_MERGED(&filter, N_("print only branches that are not merged")),
@@ -846,7 +984,8 @@ int cmd_branch(int argc,
0);
if (!delete && !rename && !copy && !edit_description && !new_upstream &&
- !show_current && !unset_upstream && argc == 0)
+ !show_current && !unset_upstream && !delete_merged &&
+ argc == 0)
list = 1;
if (filter.with_commit || filter.no_commit ||
@@ -856,7 +995,7 @@ int cmd_branch(int argc,
noncreate_actions = !!delete + !!rename + !!copy + !!new_upstream +
!!show_current + !!list + !!edit_description +
- !!unset_upstream;
+ !!unset_upstream + !!delete_merged;
if (noncreate_actions > 1)
usage_with_options(builtin_branch_usage, options);
@@ -898,6 +1037,10 @@ int cmd_branch(int argc,
(delete > 1 ? DELETE_BRANCH_FORCE : 0) |
(quiet ? DELETE_BRANCH_QUIET : 0));
goto out;
+ } else if (delete_merged) {
+ ret = delete_merged_branches(argc, argv,
+ quiet ? DELETE_BRANCH_QUIET : 0);
+ goto out;
} else if (show_current) {
print_current_branch_name();
ret = 0;
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index 3104c555f6..047ba54778 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -1839,4 +1839,189 @@ test_expect_success '--forked narrows a <pattern> argument' '
test_cmp expect actual
'
+test_expect_success '--delete-merged: setup' '
+ git init -b main upstream &&
+ (
+ cd upstream &&
+ test_commit base &&
+ git checkout -b next &&
+ test_commit next-work &&
+ git checkout main
+ ) &&
+ git init -b main other &&
+ test_commit -C other other-base &&
+ git init -b main fork
+'
+
+setup_repo_for_delete_merged () {
+ rm -rf repo &&
+ git clone upstream repo &&
+ (
+ cd repo &&
+ git remote add fork ../fork &&
+ git remote add other ../other &&
+ git config remote.pushDefault fork &&
+ git config push.default current &&
+ git fetch other
+ )
+}
+
+merged_branch () {
+ (
+ cd repo &&
+ git checkout -b "$1" "$2" &&
+ git commit --allow-empty -m "$1 work" &&
+ git push origin "$1:next" &&
+ git fetch origin &&
+ git branch --set-upstream-to="$2" "$1"
+ )
+}
+
+test_expect_success '--delete-merged deletes merged branches and spares the rest' '
+ test_when_finished "rm -rf repo" &&
+ setup_repo_for_delete_merged &&
+ merged_branch merged origin/next &&
+ (
+ cd repo &&
+ git checkout -b unmerged origin/next &&
+ git commit --allow-empty -m "unmerged work" &&
+ git branch --set-upstream-to=origin/next unmerged &&
+ git checkout -b tracks-other other/main &&
+ git branch --set-upstream-to=other/main tracks-other &&
+ git checkout --detach
+ ) &&
+ sha=$(git -C repo rev-parse --short merged) &&
+
+ git -C repo branch --delete-merged origin/next >actual 2>&1 &&
+
+ echo "Deleted branch merged (was $sha)." >expect &&
+ test_cmp expect actual &&
+ git -C repo for-each-ref --format="%(refname:short)" refs/heads/ >actual &&
+ cat >expect <<-\EOF &&
+ main
+ tracks-other
+ unmerged
+ EOF
+ test_cmp expect actual
+'
+
+test_expect_success '--delete-merged deletes merged branches and spares protected ones' '
+ test_when_finished "rm -rf repo" &&
+ setup_repo_for_delete_merged &&
+ merged_branch on-next origin/next &&
+ merged_branch checked-out origin/next &&
+ merged_branch upstream-gone origin/next &&
+ (
+ cd repo &&
+ git checkout -b mainline main &&
+ git checkout -b on-local mainline &&
+ git branch --set-upstream-to=mainline on-local &&
+ git update-ref refs/remotes/origin/topic refs/remotes/origin/next &&
+ git branch --set-upstream-to=origin/topic upstream-gone &&
+ git update-ref -d refs/remotes/origin/topic &&
+ git branch --set-upstream-to=origin/main main &&
+ git config branch.main.pushRemote origin &&
+ git checkout -b tracks-other other/main &&
+ git branch --set-upstream-to=other/main tracks-other &&
+ git checkout checked-out
+ ) &&
+
+ git -C repo branch --delete-merged origin/next mainline &&
+
+ git -C repo for-each-ref --format="%(refname:short)" refs/heads/ >actual &&
+ cat >expect <<-\EOF &&
+ checked-out
+ main
+ mainline
+ tracks-other
+ upstream-gone
+ EOF
+ test_cmp expect actual
+'
+
+test_expect_success '--delete-merged requires at least one <branch>' '
+ test_must_fail git -C forked branch --delete-merged 2>err &&
+ test_grep "requires at least one <branch>" err
+'
+
+test_expect_success '--delete-merged keeps a branch that is an upstream' '
+ test_when_finished "rm -rf repo" &&
+ setup_repo_for_delete_merged &&
+ merged_branch feature origin/next &&
+ (
+ cd repo &&
+ git checkout -b topic feature &&
+ git commit --allow-empty -m "topic work" &&
+ git branch --set-upstream-to=feature topic &&
+ git checkout --detach
+ ) &&
+
+ git -C repo branch --dry-run --delete-merged origin/next >out &&
+ test_grep ! "feature" out &&
+
+ git -C repo branch --delete-merged origin/next 2>err &&
+
+ test_must_be_empty err &&
+ git -C repo rev-parse --verify refs/heads/feature &&
+ git -C repo rev-parse --verify refs/heads/topic &&
+ echo origin/next >expect &&
+ git -C repo rev-parse --abbrev-ref feature@{upstream} >actual &&
+ test_cmp expect actual &&
+ echo feature >expect &&
+ git -C repo rev-parse --abbrev-ref topic@{upstream} >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success '--delete-merged keeps a chain of upstreams of a kept branch' '
+ test_when_finished "rm -rf repo" &&
+ setup_repo_for_delete_merged &&
+ (
+ cd repo &&
+ git branch b3 origin/next &&
+ git branch --set-upstream-to=origin/next b3 &&
+ git branch b2 origin/next &&
+ git branch --set-upstream-to=b3 b2 &&
+ git checkout -b b1 b2 &&
+ git commit --allow-empty -m "b1 work" &&
+ git branch --set-upstream-to=b2 b1 &&
+ git checkout --detach
+ ) &&
+
+ git -C repo branch --delete-merged origin/next &&
+
+ git -C repo for-each-ref --format="%(refname:short)" refs/heads/ >actual &&
+ cat >expect <<-\EOF &&
+ b1
+ b2
+ b3
+ main
+ EOF
+ test_cmp expect actual
+'
+
+test_expect_success '--delete-merged clears the upstream of a kept base whose own base is deleted' '
+ test_when_finished "rm -rf repo" &&
+ setup_repo_for_delete_merged &&
+ (
+ cd repo &&
+ git branch lower origin/next &&
+ git branch --set-upstream-to=origin/next lower &&
+ git branch mid origin/next &&
+ git branch --set-upstream-to=lower mid &&
+ git checkout -b tip mid &&
+ git commit --allow-empty -m "tip work" &&
+ git branch --set-upstream-to=mid tip &&
+ git checkout --detach
+ ) &&
+
+ git -C repo branch --delete-merged origin/next lower &&
+
+ test_must_fail git -C repo rev-parse --verify refs/heads/lower &&
+ git -C repo rev-parse --verify refs/heads/mid &&
+ test_must_fail git -C repo rev-parse mid@{upstream} &&
+ echo mid >expect &&
+ git -C repo rev-parse --abbrev-ref tip@{upstream} >actual &&
+ test_cmp expect actual
+'
+
test_done
--
gitgitgadget
^ permalink raw reply related
* Re: [PATCH v5 09/11] reftable: split up write options
From: Justin Tobler @ 2026-06-24 22:06 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Karthik Nayak, Jeff King
In-Reply-To: <20260622-b4-pks-refs-avoid-chdir-notify-reparent-v5-9-018475013dbc@pks.im>
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?
> Refactor the code by splitting out those options that configure the
> stack itself. Creating a new stack will thus only require this limited
> set of options, whereas the caller is expected to pass write options to
> all functions that end up writing tables.
Splitting this up sounds reasonable.
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
> refs/reftable-backend.c | 29 +++---
> 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 +
> t/helper/test-reftable.c | 2 +-
> 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 +-
> 14 files changed, 258 insertions(+), 198 deletions(-)
>
> diff --git a/refs/reftable-backend.c b/refs/reftable-backend.c
> index 5115a3f4ce..608d71cf10 100644
> --- a/refs/reftable-backend.c
> +++ b/refs/reftable-backend.c
> @@ -48,9 +48,9 @@ static void reftable_backend_on_reload(void *payload)
>
> static int reftable_backend_init(struct reftable_backend *be,
> const char *path,
> - const struct reftable_write_options *_opts)
Ok so now during init we only care about `struct
reftable_stack_options`. The `struct reftable_write_options` are only
needed during reftable writes.
[snip]
> +/* Options related to opening a stack. */
> +struct reftable_stack_options {
> + /*
> + * 4-byte identifier ("sha1", "s256") of the hash. Defaults to SHA1 if
> + * unset.
> + */
> + enum reftable_hash hash_id;
> +
> + /*
> + * Callback function to execute whenever the stack is being reloaded.
> + * This can be used e.g. to discard cached information that relies on
> + * the old stack's data. The payload data will be passed as argument to
> + * the callback.
> + */
> + void (*on_reload)(void *payload);
> + void *on_reload_payload;
> +};
These are the options split out from `struct reftable_write_options` and
are the options used at initialization and expected to remain consistent
across reftable writes. I assume these also won't depend on reading the
config prior to the ref store being initialzed.
[snip]
> diff --git a/reftable/reftable-writer.h b/reftable/reftable-writer.h
> index a66db415c8..6ff4ddfc60 100644
> --- a/reftable/reftable-writer.h
> +++ b/reftable/reftable-writer.h
> @@ -28,11 +28,6 @@ struct reftable_write_options {
> /* how often to write complete keys in each block. */
> uint16_t restart_interval;
>
> - /* 4-byte identifier ("sha1", "s256") of the hash.
> - * Defaults to SHA1 if unset
> - */
> - enum reftable_hash hash_id;
> -
> /* Default mode for creating files. If unset, use 0666 (+umask) */
> unsigned int default_permissions;
>
> @@ -60,15 +55,6 @@ struct reftable_write_options {
> * negative value will cause us to block indefinitely.
> */
> long lock_timeout_ms;
> -
> - /*
> - * Callback function to execute whenever the stack is being reloaded.
> - * This can be used e.g. to discard cached information that relies on
> - * the old stack's data. The payload data will be passed as argument to
> - * the callback.
> - */
> - void (*on_reload)(void *payload);
> - void *on_reload_payload;
> };
These write options are explicitly passed around during write
operations. I assume some of these options must be parsed from the
config and thus will need to be lazy-loaded to avoid "onbranch"
conditions prior to the ref store being initialzed.
The rest of this patch looks to be adjusting call sites to wire these
options through as needed and looks correct. I don't see any changes to
lazy-load write option configuration yet, but I suppose that will happen
in a subsequent patch.
-Justin
^ 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
* 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
* [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
* [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 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
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