* Re: [PATCH v3 0/8] environment: move core config globals into repo_config_values
From: Bello Olamide @ 2026-04-26 0:31 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, phillip.wood123, christian.couder, usmanakinyemi202,
kaartic.sivaraam, me
In-Reply-To: <xmqqqzo27fnu.fsf@gitster.g>
On Sun, 26 Apr 2026 at 01:02, Junio C Hamano <gitster@pobox.com> wrote:
>
> Olamide Caleb Bello <belkid98@gmail.com> writes:
>
> > Olamide Caleb Bello (8):
> > environment: move "trust_ctime" into `struct repo_config_values`
> > environment: move "check_stat" into `struct repo_config_values`
> > environment: move `zlib_compression_level` into `struct
> > repo_config_values`
> > environment: move "pack_compression_level" into `struct
> > repo_config_values`
> > environment: move "precomposed_unicode" into `struct
> > repo_config_values`
> > env: move "core_sparse_checkout_cone" into `struct repo_config_values`
> > env: move "sparse_expect_files_outside_of_patterns" into
> > `repo_config_values`
> > env: move "warn_on_object_refname_ambiguity" into `struct
> > repo_config_values`
>
> Are there differences between the ones that start with "environment:"
> vs the ones with "env:"?
>
Hi Junio,
There isn’t any semantic difference intended between
the "environment:" and "env:" prefixes
I shortened some of them to stay within the recommended subject length,
but on a second thought I agree that consistency is more important here.
I’ll standardize them in the next revision.
Thanks.
> >
> > builtin/cat-file.c | 7 ++++---
> > builtin/fast-import.c | 8 +++++---
> > builtin/index-pack.c | 3 ++-
> > builtin/mv.c | 2 +-
> > builtin/pack-objects.c | 24 +++++++++++++----------
> > builtin/sparse-checkout.c | 37 +++++++++++++++++++++---------------
> > compat/precompose_utf8.c | 20 +++++++++++++-------
> > diff.c | 3 ++-
> > dir.c | 3 ++-
> > entry.c | 3 ++-
> > environment.c | 40 +++++++++++++++++++++------------------
> > environment.h | 19 ++++++++++---------
> > http-push.c | 3 ++-
> > object-file.c | 6 ++++--
> > object-name.c | 3 ++-
> > revision.c | 7 ++++---
> > sparse-index.c | 4 ++--
> > statinfo.c | 12 +++++++-----
> > submodule.c | 7 ++++---
> > upload-pack.c | 3 ++-
> > 20 files changed, 126 insertions(+), 88 deletions(-)
^ permalink raw reply
* Re: [PATCH v3 0/8] environment: move core config globals into repo_config_values
From: Junio C Hamano @ 2026-04-26 0:01 UTC (permalink / raw)
To: Olamide Caleb Bello
Cc: git, phillip.wood123, christian.couder, usmanakinyemi202,
kaartic.sivaraam, me
In-Reply-To: <20260423165432.143598-1-belkid98@gmail.com>
Olamide Caleb Bello <belkid98@gmail.com> writes:
> Olamide Caleb Bello (8):
> environment: move "trust_ctime" into `struct repo_config_values`
> environment: move "check_stat" into `struct repo_config_values`
> environment: move `zlib_compression_level` into `struct
> repo_config_values`
> environment: move "pack_compression_level" into `struct
> repo_config_values`
> environment: move "precomposed_unicode" into `struct
> repo_config_values`
> env: move "core_sparse_checkout_cone" into `struct repo_config_values`
> env: move "sparse_expect_files_outside_of_patterns" into
> `repo_config_values`
> env: move "warn_on_object_refname_ambiguity" into `struct
> repo_config_values`
Are there differences between the ones that start with "environment:"
vs the ones with "env:"?
>
> builtin/cat-file.c | 7 ++++---
> builtin/fast-import.c | 8 +++++---
> builtin/index-pack.c | 3 ++-
> builtin/mv.c | 2 +-
> builtin/pack-objects.c | 24 +++++++++++++----------
> builtin/sparse-checkout.c | 37 +++++++++++++++++++++---------------
> compat/precompose_utf8.c | 20 +++++++++++++-------
> diff.c | 3 ++-
> dir.c | 3 ++-
> entry.c | 3 ++-
> environment.c | 40 +++++++++++++++++++++------------------
> environment.h | 19 ++++++++++---------
> http-push.c | 3 ++-
> object-file.c | 6 ++++--
> object-name.c | 3 ++-
> revision.c | 7 ++++---
> sparse-index.c | 4 ++--
> statinfo.c | 12 +++++++-----
> submodule.c | 7 ++++---
> upload-pack.c | 3 ++-
> 20 files changed, 126 insertions(+), 88 deletions(-)
^ permalink raw reply
* Re: [PATCH] alias: restore support for simple dotted aliases
From: Jeff King @ 2026-04-25 23:47 UTC (permalink / raw)
To: Jonatan Holmgren; +Cc: Junio C Hamano, git, rsch, michael.grossfeld
In-Reply-To: <20260425232916.GA29816@coredump.intra.peff.net>
On Sat, Apr 25, 2026 at 07:29:16PM -0400, Jeff King wrote:
> On Sat, Apr 25, 2026 at 11:57:24AM +0200, Jonatan Holmgren wrote:
>
> > That is a challenge we are going to have to consider. I think reserving
> > `command` is a worthwhile compromise, but obviously we cannot do that for
> > arbitrary future keys such as `help`, `hidden`, etc.
>
> We don't necessarily have to reserve them. When we see alias.foo.bar, we
> could consider it as both alias "foo.bar" and the "bar" key of alias
> "foo", without regard to what is in "bar" (i.e., whether it is "command"
> or "help", etc). I.e., don't "fall back" but allow two overlapping
> namespace.s
>
> That is the most backwards-compatible thing we could do, but does create
> some interesting situations.
For reference, I mean something like this:
diff --git a/alias.c b/alias.c
index ec9833dd30..07c6bd3645 100644
--- a/alias.c
+++ b/alias.c
@@ -34,16 +34,20 @@ static int config_alias_cb(const char *var, const char *value,
if (subsection && !subsection_len)
subsection = NULL;
- if (subsection && strcmp(key, "command"))
- return 0;
-
if (data->alias) {
int match;
if (subsection)
- match = (strlen(data->alias) == subsection_len &&
- !strncmp(data->alias, subsection,
- subsection_len));
+ /*
+ * alias.foo.command always matches "foo", but for
+ * historical compatibility also match alias.foo.bar as
+ * "foo.bar", even when "bar" is "command" or any other
+ * key we happen to know about.
+ */
+ match = (!strcmp(key, "command") &&
+ strlen(data->alias) == subsection_len &&
+ !strncmp(data->alias, subsection, subsection_len))
+ || !strcmp(data->alias, subsection);
else
match = !strcasecmp(data->alias, key);
@@ -59,8 +63,23 @@ static int config_alias_cb(const char *var, const char *value,
return config_error_nonbool(var);
if (subsection)
+ /*
+ * If it's not alias.foo.command, then either it's a
+ * historical alias (git "foo.bar"), or it's some
+ * metadata not support yet by this version
+ * ("alias.foo.help" or similar).
+ *
+ * We'll guess it's the former and include the whole
+ * "foo.bar" in the list.
+ *
+ * We might want to suppress duplicates when we see both
+ * alias.foo.command and alias.foo.help, since that's
+ * what a hypothetical future version might understand.
+ */
item = string_list_append_nodup(data->list,
- xmemdupz(subsection, subsection_len));
+ !strcmp(key, "command")
+ ? xmemdupz(subsection, subsection_len)
+ : xstrdup(subsection));
else
item = string_list_append(data->list, key);
item->util = xstrdup(value);
-Peff
^ permalink raw reply related
* Re: [PATCH] alias: restore support for simple dotted aliases
From: Jeff King @ 2026-04-25 23:29 UTC (permalink / raw)
To: Jonatan Holmgren; +Cc: Junio C Hamano, git, rsch, michael.grossfeld
In-Reply-To: <40408c99-7e2a-4cf6-b9b2-6d0e0da3b2c5@jontes.page>
On Sat, Apr 25, 2026 at 11:57:24AM +0200, Jonatan Holmgren wrote:
> That is a challenge we are going to have to consider. I think reserving
> `command` is a worthwhile compromise, but obviously we cannot do that for
> arbitrary future keys such as `help`, `hidden`, etc.
We don't necessarily have to reserve them. When we see alias.foo.bar, we
could consider it as both alias "foo.bar" and the "bar" key of alias
"foo", without regard to what is in "bar" (i.e., whether it is "command"
or "help", etc). I.e., don't "fall back" but allow two overlapping
namespace.s
That is the most backwards-compatible thing we could do, but does create
some interesting situations.
If you define alias.foo.command with the intent to allow "git foo", that
is also creating the identical alias "git foo.command". Probably nobody
cares too much, as if you did not mean to make "foo.command" you would
never invoke it. We'd probably want to omit it when listing aliases,
though.
If we later introduce alias.foo.help, the same thing applies but with a
twist. Running "git foo.help" will invoke that key as an alias command,
but it is probably not a sensible command in the first place. But again,
I'm not sure why anybody would try to do so.
That said, I don't think reserving "command" or even some future names
is that painful in the long run. The three-level syntax is a superset of
the old functionality, and in general the best solution will be for
users to convert their old aliases to it. The benefits of providing the
fallback compatibility are:
1. Users can avoid having to do anything at all. And that will still
be true for the majority, unless they happen to have a three-level
alias that ends with ".command" (for now) or eventually ".help",
etc. We don't have any hard data, but I have to imagine that the
numbers here are vanishingly small.
2. Cross-version compatibility. You can't use alias.pull.sub.command
in Git v2.53 and older, so it's otherwise impossible to have config
that works both there and with v2.54.
But as time goes on, wanting to cross that version boundary becomes
less and less likely. If we we eventually introduce ".help" and it
breaks somebody foo.help alias, suggesting alias.foo.help.command
will work all the way back to Git v2.54, which may be sufficient.
> One possible compromise would be to reserve `command` and `alias-*`, as
> neither seems very likely to exist in users' historical alias names.
>
> A new namespace makes the most sense from a namespace-pollution point of
> view, but I struggle to see that as good UX. Even a separate namespace
> only for alias metadata would make more sense to me than moving aliases
> entirely, since subsection aliases with just `command` will likely be far
> more common than any future metadata keys, but this is not something I see
> as a good solution either.
Yeah. Obviously a totally separate namespace makes all of this go away,
but it feels like we are sacrificing the experience going forward in
order to accommodate some fairly unlikely historical clashes.
-Peff
^ permalink raw reply
* gh
From: Harald Nordgren @ 2026-04-25 22:54 UTC (permalink / raw)
To: ben.knoble; +Cc: git, gitgitgadget, gitster, haraldnordgren
In-Reply-To: <E5737766-2A41-46A6-A3FD-530CAC5076F4@gmail.com>
> Isn’t that exactly what
>
> git fetch origin main
>
> does? (Might need to expand the refspec.)
Very good point, I will update it!
Harald
^ permalink raw reply
* Re: [PATCH] remote: add --set-head option to 'git remote add'
From: Jeff King @ 2026-04-25 22:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Harald Nordgren via GitGitGadget, git, Harald Nordgren
In-Reply-To: <xmqqzf2q8zxc.fsf@gitster.g>
On Sun, Apr 26, 2026 at 06:58:55AM +0900, Junio C Hamano wrote:
> "Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > From: Harald Nordgren <haraldnordgren@gmail.com>
> >
> > Mirror the behavior 'git clone' applies to its first remote: after
> > fetching, set refs/remotes/<name>/HEAD to the remote's default branch.
> >
> > Equivalent to running:
> >
> > git remote add -f <name> <url>
> > git remote set-head <name> -a
> >
> > The new option implies --fetch.
>
> Should this option (and the auto mode of "git remote set-head") even
> be necessary as an extra thing that the end-user should need to be
> aware of these days?
>
> It feels to me that the "fetch" part of "git remote add --fetch"
> command should behave in line with what "git fetch" from the remote
> does with "remote.<name>.followRemoteHEAD" configuration.
It already does, doesn't it? Doing:
$ git init
$ git remote add --fetch origin /path/to/some/repo
$ git for-each-ref
shows an origin/HEAD link.
Which I think is not too surprising, as it is just calling "git fetch"
under the hood.
-Peff
^ permalink raw reply
* Re: [PATCH] remote: add --set-head option to 'git remote add'
From: Junio C Hamano @ 2026-04-25 21:58 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget; +Cc: git, Harald Nordgren
In-Reply-To: <pull.2283.git.git.1777115978088.gitgitgadget@gmail.com>
"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> Mirror the behavior 'git clone' applies to its first remote: after
> fetching, set refs/remotes/<name>/HEAD to the remote's default branch.
>
> Equivalent to running:
>
> git remote add -f <name> <url>
> git remote set-head <name> -a
>
> The new option implies --fetch.
Should this option (and the auto mode of "git remote set-head") even
be necessary as an extra thing that the end-user should need to be
aware of these days?
It feels to me that the "fetch" part of "git remote add --fetch"
command should behave in line with what "git fetch" from the remote
does with "remote.<name>.followRemoteHEAD" configuration.
Of course, the current implementation may not do so, and that is why
you are sending this patch. A patch would need to plumb through the
mechanism, but I think this should be pretty much automatic without
giving more control than what the users already have.
And because remote.<name>.followRemoteHEAD that is unconfigured is
the same as setting it to "create", it means "git remote add -f"
will behave just like "git clone" would to remember the upstream
choice of which of their branches is the primary one (which is what
HEAD in the publishing repository means), unless the variable is
explicitly configured to "never".
IOW, I think this should/can be done as a bugfix, i.e.,
Even though "git clone -o <name> <URL>" does, "git remote add
--fetch <name> <URL>" does not create refs/remotes/<name>/HEAD.
Fix it by making it honor the remote.<name>.followRemoteHEAD
configuration variable, which was invented exactly for this
purpose..
or something.
^ permalink raw reply
* Re: Multiple remotes
From: Ben Knoble @ 2026-04-25 21:57 UTC (permalink / raw)
To: Harald Nordgren; +Cc: gitster, git, gitgitgadget, haraldnordgren
In-Reply-To: <20260425175824.48380-1-haraldnordgren@gmail.com>
> Le 25 avr. 2026 à 13:58, Harald Nordgren <haraldnordgren@gmail.com> a écrit :
>
>
>>
>> The last one was a rhetorical question. I do not want to see such a
>> configuration variable to implicitly trigger fetching at all.
>
> 🤣
>
> Good to clarify that when working with me so that I don't go ahead and
> implement that!
>
>> If you are merely starting at a single arbitrary
>> commit, instead of anticipating to having to repeatedly sync with
>> the remote-tracking branch that will subsequently move, there is no
>> point jumping to a "freshest" commit that you haven't even seen let
>> alone inspected (i.e., you do not even know if it is a good base to
>> build on).
>
> Not sure I understand this sentiment. For better or worse, the latest
> commit will decide what you have to work with -- unless we expect it to be
> reverted or forced pushed over.
>
> What better starting point is there?
>
>> For a starter, if you interact
>> with a repository with two or more branches, should
>>
>> $ git checkout --track=fetch -b topic origin/main
>>
>> update an unrelated remote-tracking branch origin/maint from the
>> same remote? As I already said, most Git tools _depend_ on the
>> stability of remote-tracking branches
>
> This is an interesting question, and it's very likely that I am missing
> some nuance here. However, with that said what option does the developer
> have, you have to accept that the upstream changes constantly when others
> are working on it. What good does it do to keep the "head in the sand" any
> longer than necessary?
>
> I'm not sure there is a way to fetch only 'origin/main' and avoid
> 'origin/maint'? Maybe, maybe, if that exists it could be useful here.
Isn’t that exactly what
git fetch origin main
does? (Might need to expand the refspec.)
>
>> still on a leave
>
> Enjoy your vacation! I don't expect any response from you until you're back!
>
>
> Harald
>
^ permalink raw reply
* [PATCH v2] checkout: add --fetch to fetch remote before resolving start-point
From: Harald Nordgren via GitGitGadget @ 2026-04-25 18:12 UTC (permalink / raw)
To: git
Cc: Ramsay Jones, D. Ben Knoble, Kristoffer Haugsbakk, Marc Branchaud,
Harald Nordgren, Harald Nordgren
In-Reply-To: <pull.2281.git.git.1777024991531.gitgitgadget@gmail.com>
From: Harald Nordgren <haraldnordgren@gmail.com>
A common workflow is:
git fetch origin
git checkout -b new_branch origin/some-branch
The first command exists purely so the second sees an up-to-date view
of the remote. If it is forgotten, origin/some-branch points at a stale
commit and the new local branch is created from the wrong start point.
Teach checkout (and switch) a --fetch flag that folds the two steps
into one:
git checkout --fetch -b new_branch origin/some-branch
When --fetch is given and <start-point> names a configured remote
(either bare, like "origin", or prefixed, like "origin/foo"), fetch
that remote before resolving the ref. Abort the checkout if the fetch
fails.
Also add a checkout.fetch config to enable this by default.
Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
---
checkout: add --fetch to fetch remote before resolving start-point
* Rename the config from checkout.autoFetch to checkout.fetch, so it
matches the --fetch option name.
* Rename the internal struct field from auto_fetch to fetch for
consistency with the option and config names.
* Reword the commit message to lead with the problem (forgetting 'git
fetch' and ending up with a stale start-point) before describing the
solution.
* Document --fetch / --no-fetch in git-checkout and git-switch, and
document checkout.fetch in the config reference.
* Use "remote-tracking branch" instead of "remote-tracking ref" in the
option help text.
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2281%2FHaraldNordgren%2Fcheckout-fetch-start-point-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2281/HaraldNordgren/checkout-fetch-start-point-v2
Pull-Request: https://github.com/git/git/pull/2281
Range-diff vs v1:
1: e2fa50ff40 ! 1: 13074c9fea checkout: add --fetch to fetch remote before resolving start-point
@@ Metadata
## Commit message ##
checkout: add --fetch to fetch remote before resolving start-point
- Add a --fetch option to git checkout and git switch, plus a
- checkout.autoFetch config to enable it by default. When set and the
- start-point argument names a configured remote (either bare, like
- "origin", or prefixed, like "origin/foo"), fetch that remote before
- resolving the ref. Aborts the checkout if the fetch fails.
+ A common workflow is:
+
+ git fetch origin
+ git checkout -b new_branch origin/some-branch
+
+ The first command exists purely so the second sees an up-to-date view
+ of the remote. If it is forgotten, origin/some-branch points at a stale
+ commit and the new local branch is created from the wrong start point.
+
+ Teach checkout (and switch) a --fetch flag that folds the two steps
+ into one:
+
+ git checkout --fetch -b new_branch origin/some-branch
+
+ When --fetch is given and <start-point> names a configured remote
+ (either bare, like "origin", or prefixed, like "origin/foo"), fetch
+ that remote before resolving the ref. Abort the checkout if the fetch
+ fails.
+
+ Also add a checkout.fetch config to enable this by default.
Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
+ ## Documentation/config/checkout.adoc ##
+@@ Documentation/config/checkout.adoc: commands or functionality in the future.
+ option in `git checkout` and `git switch`. See
+ linkgit:git-switch[1] and linkgit:git-checkout[1].
+
++`checkout.fetch`::
++ Provides the default value for the `--fetch` or `--no-fetch`
++ option in `git checkout` and `git switch`. See
++ linkgit:git-switch[1] and linkgit:git-checkout[1].
++
+ `checkout.workers`::
+ The number of parallel workers to use when updating the working tree.
+ The default is one, i.e. sequential execution. If set to a value less
+
+ ## Documentation/git-checkout.adoc ##
+@@ Documentation/git-checkout.adoc: linkgit:git-config[1].
+ The default behavior can be set via the `checkout.guess` configuration
+ variable.
+
++`--fetch`::
++`--no-fetch`::
++ If _<start-point>_ names a configured remote -- either bare,
++ like `origin` (which resolves to the remote's default branch),
++ or in _<remote>/<branch>_ form -- run `git fetch` on that
++ remote before resolving _<start-point>_. If the fetch fails,
++ the checkout is aborted and no local branch is created.
+++
++The default behavior can be set via the `checkout.fetch` configuration
++variable.
++
+ `-l`::
+ Create the new branch's reflog; see linkgit:git-branch[1] for
+ details.
+
+ ## Documentation/git-switch.adoc ##
+@@ Documentation/git-switch.adoc: ambiguous but exists on the 'origin' remote. See also
+ The default behavior can be set via the `checkout.guess` configuration
+ variable.
+
++`--fetch`::
++`--no-fetch`::
++ If _<start-point>_ names a configured remote -- either bare,
++ like `origin` (which resolves to the remote's default branch),
++ or in _<remote>/<branch>_ form -- run `git fetch` on that
++ remote before resolving _<start-point>_. If the fetch fails,
++ the switch is aborted and no local branch is created.
+++
++The default behavior can be set via the `checkout.fetch` configuration
++variable.
++
+ `-f`::
+ `--force`::
+ An alias for `--discard-changes`.
+
## builtin/checkout.c ##
@@
#include "repo-settings.h"
@@ builtin/checkout.c: struct checkout_opts {
int count_checkout_paths;
int overlay_mode;
int dwim_new_local_branch;
-+ int auto_fetch;
++ int fetch;
int discard_changes;
int accept_ref;
int accept_pathspec;
@@ builtin/checkout.c: static int git_checkout_config(const char *var, const char *
opts->dwim_new_local_branch = git_config_bool(var, value);
return 0;
}
-+ if (!strcmp(var, "checkout.autofetch")) {
-+ opts->auto_fetch = git_config_bool(var, value);
++ if (!strcmp(var, "checkout.fetch")) {
++ opts->fetch = git_config_bool(var, value);
+ return 0;
+ }
@@ builtin/checkout.c: static int checkout_main(int argc, const char **argv, const
- &new_branch_info, opts, &rev);
+ int n;
+
-+ if (opts->auto_fetch)
++ if (opts->fetch)
+ fetch_remote_for_start_point(argv[0]);
+
+ n = parse_branchname_arg(argc, argv, dwim_ok, which_command,
@@ builtin/checkout.c: int cmd_checkout(int argc,
OPT_BOOL(0, "overlay", &opts.overlay_mode, N_("use overlay mode (default)")),
OPT_BOOL(0, "auto-advance", &opts.auto_advance,
N_("auto advance to the next file when selecting hunks interactively")),
-+ OPT_BOOL(0, "fetch", &opts.auto_fetch,
-+ N_("fetch from the remote first if <start-point> is a remote-tracking ref")),
++ OPT_BOOL(0, "fetch", &opts.fetch,
++ N_("fetch from the remote first if <start-point> is a remote-tracking branch")),
OPT_END()
};
@@ builtin/checkout.c: int cmd_switch(int argc,
N_("second guess 'git switch <no-such-branch>'")),
OPT_BOOL(0, "discard-changes", &opts.discard_changes,
N_("throw away local modifications")),
-+ OPT_BOOL(0, "fetch", &opts.auto_fetch,
-+ N_("fetch from the remote first if <start-point> is a remote-tracking ref")),
++ OPT_BOOL(0, "fetch", &opts.fetch,
++ N_("fetch from the remote first if <start-point> is a remote-tracking branch")),
OPT_END()
};
@@ t/t7201-co.sh: test_expect_success 'tracking info copied with autoSetupMerge=inh
+ test_must_fail git rev-parse --verify refs/heads/bogus
+'
+
-+test_expect_success 'checkout.autoFetch=true enables fetching without --fetch' '
++test_expect_success 'checkout.fetch=true enables fetching without --fetch' '
+ git checkout main &&
+ git -C fetch_upstream checkout -b fetch_cfg &&
+ test_commit -C fetch_upstream u_cfg &&
+ test_must_fail git rev-parse --verify refs/remotes/fetch_upstream/fetch_cfg &&
-+ git -c checkout.autoFetch=true checkout -b local_cfg fetch_upstream/fetch_cfg &&
++ git -c checkout.fetch=true checkout -b local_cfg fetch_upstream/fetch_cfg &&
+ test_cmp_rev refs/remotes/fetch_upstream/fetch_cfg HEAD
+'
+
Documentation/config/checkout.adoc | 5 +++
Documentation/git-checkout.adoc | 11 +++++++
Documentation/git-switch.adoc | 11 +++++++
builtin/checkout.c | 48 ++++++++++++++++++++++++++--
t/t7201-co.sh | 51 ++++++++++++++++++++++++++++++
t/t9902-completion.sh | 1 +
6 files changed, 125 insertions(+), 2 deletions(-)
diff --git a/Documentation/config/checkout.adoc b/Documentation/config/checkout.adoc
index e35d212969..c95f72b38e 100644
--- a/Documentation/config/checkout.adoc
+++ b/Documentation/config/checkout.adoc
@@ -22,6 +22,11 @@ commands or functionality in the future.
option in `git checkout` and `git switch`. See
linkgit:git-switch[1] and linkgit:git-checkout[1].
+`checkout.fetch`::
+ Provides the default value for the `--fetch` or `--no-fetch`
+ option in `git checkout` and `git switch`. See
+ linkgit:git-switch[1] and linkgit:git-checkout[1].
+
`checkout.workers`::
The number of parallel workers to use when updating the working tree.
The default is one, i.e. sequential execution. If set to a value less
diff --git a/Documentation/git-checkout.adoc b/Documentation/git-checkout.adoc
index 43ccf47cf6..f20e2f4c8c 100644
--- a/Documentation/git-checkout.adoc
+++ b/Documentation/git-checkout.adoc
@@ -201,6 +201,17 @@ linkgit:git-config[1].
The default behavior can be set via the `checkout.guess` configuration
variable.
+`--fetch`::
+`--no-fetch`::
+ If _<start-point>_ names a configured remote -- either bare,
+ like `origin` (which resolves to the remote's default branch),
+ or in _<remote>/<branch>_ form -- run `git fetch` on that
+ remote before resolving _<start-point>_. If the fetch fails,
+ the checkout is aborted and no local branch is created.
++
+The default behavior can be set via the `checkout.fetch` configuration
+variable.
+
`-l`::
Create the new branch's reflog; see linkgit:git-branch[1] for
details.
diff --git a/Documentation/git-switch.adoc b/Documentation/git-switch.adoc
index 87707e9265..3826ed9066 100644
--- a/Documentation/git-switch.adoc
+++ b/Documentation/git-switch.adoc
@@ -110,6 +110,17 @@ ambiguous but exists on the 'origin' remote. See also
The default behavior can be set via the `checkout.guess` configuration
variable.
+`--fetch`::
+`--no-fetch`::
+ If _<start-point>_ names a configured remote -- either bare,
+ like `origin` (which resolves to the remote's default branch),
+ or in _<remote>/<branch>_ form -- run `git fetch` on that
+ remote before resolving _<start-point>_. If the fetch fails,
+ the switch is aborted and no local branch is created.
++
+The default behavior can be set via the `checkout.fetch` configuration
+variable.
+
`-f`::
`--force`::
An alias for `--discard-changes`.
diff --git a/builtin/checkout.c b/builtin/checkout.c
index e031e61886..b2a34f0f00 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -30,7 +30,9 @@
#include "repo-settings.h"
#include "resolve-undo.h"
#include "revision.h"
+#include "run-command.h"
#include "setup.h"
+#include "strvec.h"
#include "submodule.h"
#include "symlinks.h"
#include "trace2.h"
@@ -61,6 +63,7 @@ struct checkout_opts {
int count_checkout_paths;
int overlay_mode;
int dwim_new_local_branch;
+ int fetch;
int discard_changes;
int accept_ref;
int accept_pathspec;
@@ -112,6 +115,34 @@ struct branch_info {
char *checkout;
};
+static void fetch_remote_for_start_point(const char *arg)
+{
+ const char *slash;
+ char *remote_name;
+ struct remote *remote;
+ struct child_process cmd = CHILD_PROCESS_INIT;
+
+ if (!arg || !*arg)
+ return;
+
+ slash = strchr(arg, '/');
+ if (slash == arg)
+ return;
+ remote_name = slash ? xstrndup(arg, slash - arg) : xstrdup(arg);
+
+ remote = remote_get(remote_name);
+ if (!remote || !remote_is_configured(remote, 1)) {
+ free(remote_name);
+ return;
+ }
+
+ strvec_pushl(&cmd.args, "fetch", remote_name, NULL);
+ cmd.git_cmd = 1;
+ free(remote_name);
+ if (run_command(&cmd))
+ die(_("failed to fetch start-point '%s'"), arg);
+}
+
static void branch_info_release(struct branch_info *info)
{
free(info->name);
@@ -1237,6 +1268,10 @@ static int git_checkout_config(const char *var, const char *value,
opts->dwim_new_local_branch = git_config_bool(var, value);
return 0;
}
+ if (!strcmp(var, "checkout.fetch")) {
+ opts->fetch = git_config_bool(var, value);
+ return 0;
+ }
if (starts_with(var, "submodule."))
return git_default_submodule_config(var, value, NULL);
@@ -1942,8 +1977,13 @@ static int checkout_main(int argc, const char **argv, const char *prefix,
opts->dwim_new_local_branch &&
opts->track == BRANCH_TRACK_UNSPECIFIED &&
!opts->new_branch;
- int n = parse_branchname_arg(argc, argv, dwim_ok, which_command,
- &new_branch_info, opts, &rev);
+ int n;
+
+ if (opts->fetch)
+ fetch_remote_for_start_point(argv[0]);
+
+ n = parse_branchname_arg(argc, argv, dwim_ok, which_command,
+ &new_branch_info, opts, &rev);
argv += n;
argc -= n;
} else if (!opts->accept_ref && opts->from_treeish) {
@@ -2052,6 +2092,8 @@ int cmd_checkout(int argc,
OPT_BOOL(0, "overlay", &opts.overlay_mode, N_("use overlay mode (default)")),
OPT_BOOL(0, "auto-advance", &opts.auto_advance,
N_("auto advance to the next file when selecting hunks interactively")),
+ OPT_BOOL(0, "fetch", &opts.fetch,
+ N_("fetch from the remote first if <start-point> is a remote-tracking branch")),
OPT_END()
};
@@ -2102,6 +2144,8 @@ int cmd_switch(int argc,
N_("second guess 'git switch <no-such-branch>'")),
OPT_BOOL(0, "discard-changes", &opts.discard_changes,
N_("throw away local modifications")),
+ OPT_BOOL(0, "fetch", &opts.fetch,
+ N_("fetch from the remote first if <start-point> is a remote-tracking branch")),
OPT_END()
};
diff --git a/t/t7201-co.sh b/t/t7201-co.sh
index 9bcf7c0b40..f5729f0831 100755
--- a/t/t7201-co.sh
+++ b/t/t7201-co.sh
@@ -801,4 +801,55 @@ test_expect_success 'tracking info copied with autoSetupMerge=inherit' '
test_cmp_config "" --default "" branch.main2.merge
'
+test_expect_success 'setup upstream for --fetch tests' '
+ git checkout main &&
+ git init fetch_upstream &&
+ test_commit -C fetch_upstream u_main &&
+ git remote add fetch_upstream fetch_upstream &&
+ git fetch fetch_upstream &&
+ git -C fetch_upstream checkout -b fetch_new &&
+ test_commit -C fetch_upstream u_new
+'
+
+test_expect_success 'checkout --fetch -b picks up branch created upstream after clone' '
+ git checkout main &&
+ test_must_fail git rev-parse --verify refs/remotes/fetch_upstream/fetch_new &&
+ git checkout --fetch -b local_new fetch_upstream/fetch_new &&
+ test_cmp_rev refs/remotes/fetch_upstream/fetch_new HEAD
+'
+
+test_expect_success 'checkout --fetch with bare remote name fetches the remote' '
+ git checkout main &&
+ git -C fetch_upstream checkout -b fetch_new2 &&
+ test_commit -C fetch_upstream u_new2 &&
+ test_must_fail git rev-parse --verify refs/remotes/fetch_upstream/fetch_new2 &&
+ git checkout --fetch -b local_from_remote fetch_upstream &&
+ git rev-parse --verify refs/remotes/fetch_upstream/fetch_new2
+'
+
+test_expect_success 'checkout --fetch aborts and does not create branch on fetch failure' '
+ git checkout main &&
+ test_might_fail git branch -D bogus &&
+ test_must_fail git checkout --fetch -b bogus fetch_upstream/does_not_exist &&
+ test_must_fail git rev-parse --verify refs/heads/bogus
+'
+
+test_expect_success 'checkout.fetch=true enables fetching without --fetch' '
+ git checkout main &&
+ git -C fetch_upstream checkout -b fetch_cfg &&
+ test_commit -C fetch_upstream u_cfg &&
+ test_must_fail git rev-parse --verify refs/remotes/fetch_upstream/fetch_cfg &&
+ git -c checkout.fetch=true checkout -b local_cfg fetch_upstream/fetch_cfg &&
+ test_cmp_rev refs/remotes/fetch_upstream/fetch_cfg HEAD
+'
+
+test_expect_success 'switch --fetch -c picks up branch created upstream after clone' '
+ git checkout main &&
+ git -C fetch_upstream checkout -b fetch_switch &&
+ test_commit -C fetch_upstream u_switch &&
+ test_must_fail git rev-parse --verify refs/remotes/fetch_upstream/fetch_switch &&
+ git switch --fetch -c local_switch fetch_upstream/fetch_switch &&
+ test_cmp_rev refs/remotes/fetch_upstream/fetch_switch HEAD
+'
+
test_done
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 2f9a597ec7..dc1d63669f 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -2602,6 +2602,7 @@ test_expect_success 'double dash "git checkout"' '
--ignore-other-worktrees Z
--recurse-submodules Z
--auto-advance Z
+ --fetch Z
--progress Z
--guess Z
--no-guess Z
base-commit: 94f057755b7941b321fd11fec1b2e3ca5313a4e0
--
gitgitgadget
^ permalink raw reply related
* gh
From: Harald Nordgren @ 2026-04-25 18:07 UTC (permalink / raw)
To: ben.knoble; +Cc: git, gitgitgadget, haraldnordgren
In-Reply-To: <6F9060F0-20EB-4B60-8677-86DA2AB39B35@gmail.com>
> I’m not totally opposed to this convenience, but couldn’t we also just teach gh to run set-head as a second command?
We probably could, and maybe we should.
One argument for this new options is that I believe 'git clone' has this
behavior, so it's attractive if forking (adding a secondary remote) could
work in the same way as clone (adding the first remote).
Harald
^ permalink raw reply
* Multiple remotes
From: Harald Nordgren @ 2026-04-25 17:58 UTC (permalink / raw)
To: gitster; +Cc: git, gitgitgadget, haraldnordgren
In-Reply-To: <xmqqfr4jwxzi.fsf@gitster.g>
> The last one was a rhetorical question. I do not want to see such a
> configuration variable to implicitly trigger fetching at all.
🤣
Good to clarify that when working with me so that I don't go ahead and
implement that!
> If you are merely starting at a single arbitrary
> commit, instead of anticipating to having to repeatedly sync with
> the remote-tracking branch that will subsequently move, there is no
> point jumping to a "freshest" commit that you haven't even seen let
> alone inspected (i.e., you do not even know if it is a good base to
> build on).
Not sure I understand this sentiment. For better or worse, the latest
commit will decide what you have to work with -- unless we expect it to be
reverted or forced pushed over.
What better starting point is there?
> For a starter, if you interact
> with a repository with two or more branches, should
>
> $ git checkout --track=fetch -b topic origin/main
>
> update an unrelated remote-tracking branch origin/maint from the
> same remote? As I already said, most Git tools _depend_ on the
> stability of remote-tracking branches
This is an interesting question, and it's very likely that I am missing
some nuance here. However, with that said what option does the developer
have, you have to accept that the upstream changes constantly when others
are working on it. What good does it do to keep the "head in the sand" any
longer than necessary?
I'm not sure there is a way to fetch only 'origin/main' and avoid
'origin/maint'? Maybe, maybe, if that exists it could be useful here.
> still on a leave
Enjoy your vacation! I don't expect any response from you until you're back!
Harald
^ permalink raw reply
* Wrong subject line
From: Harald Nordgren @ 2026-04-25 17:48 UTC (permalink / raw)
To: marcnarc; +Cc: git, gitgitgadget, haraldnordgren
In-Reply-To: <42a620db-6110-4894-97fb-8e49ec577817@gmail.com>
I know you are not Ben. Forgot to change the subject line from a previous message.
Harald
^ permalink raw reply
* Wrong subject line
From: Harald Nordgren @ 2026-04-25 17:44 UTC (permalink / raw)
To: haraldnordgren; +Cc: git, gitgitgadget, kristofferhaugsbakk
In-Reply-To: <20260425174157.44868-1-haraldnordgren@gmail.com>
I know you are not Ben. Forgot to change the subject line from a previous message.
Harald
^ permalink raw reply
* Wrong subject line
From: Harald Nordgren @ 2026-04-25 17:44 UTC (permalink / raw)
To: haraldnordgren; +Cc: ben.knoble, git, gitgitgadget
In-Reply-To: <20260425172451.21365-1-haraldnordgren@gmail.com>
I know you are not Ben. Forgot to change the subject line from a previous message.
Harald
^ permalink raw reply
* Comments on Phillip's review
From: Harald Nordgren @ 2026-04-25 17:41 UTC (permalink / raw)
To: kristofferhaugsbakk; +Cc: git, gitgitgadget, haraldnordgren
In-Reply-To: <89f923bf-e5fc-4557-a2f0-d240db07eaf9@app.fastmail.com>
> > Add a --fetch option to git checkout and git switch, plus a
> > checkout.autoFetch config to enable it by default. When set and the
>
> Why is the config not `checkout.config`? So it’s named the same as the
> option (modulo snake case/camel case which is not relevant here).
Will rename the config to 'checkout.fetch'.
> The motivation for why this is being proposed maybe might as well go in
> the commit message. Maybe that’s just me.
>
> The commit message just says that “this thing is added”. Not why.
I will update it.
> I guess a later version will have the changes to the documentation.
I forgot that, will add it!
> s/remote-tracking ref/remote-tracking branch/ ?
>
> git(1) doesn’t have a namespace for tracking refs in general.
👍
Harald
^ permalink raw reply
* Comments on Phillip's review
From: Harald Nordgren @ 2026-04-25 17:24 UTC (permalink / raw)
To: ben.knoble; +Cc: git, gitgitgadget, haraldnordgren
In-Reply-To: <CALnO6CCNoo8y2V5KmE0KQ6qDurZELipFowcr=ZpZ3ocVB-uLjA@mail.gmail.com>
> When you realize this, "git pull --rebase" should help correct it.
Sure. I always run with
```
git config --global pull.rebase=true
```
I love rebasing and recomdend it to all colleagues that will listen, but
it still sucks to expose yourself to a possible merge conflict when you
realize you worked hours on top of a stale main branch.
> I could certainly see this being convenient.
🙌🏻
Harald
^ permalink raw reply
* Re: [PATCH] remote: add --set-head option to 'git remote add'
From: Ben Knoble @ 2026-04-25 17:20 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget; +Cc: git, Harald Nordgren
In-Reply-To: <pull.2283.git.git.1777115978088.gitgitgadget@gmail.com>
> Le 25 avr. 2026 à 07:19, Harald Nordgren via GitGitGadget <gitgitgadget@gmail.com> a écrit :
>
> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> Mirror the behavior 'git clone' applies to its first remote: after
> fetching, set refs/remotes/<name>/HEAD to the remote's default branch.
>
> Equivalent to running:
>
> git remote add -f <name> <url>
> git remote set-head <name> -a
>
> The new option implies --fetch.
>
> Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
> ---
> remote: add --set-head option to 'git remote add'
>
> When using GitHub's gh tool to fork a repo, it seems that set-head isn't
> run on the upstream remote. So its default branch is not recorded
> locally, meaning that 'git log fork' will not work.
>
> With git remote add --set-head upstream , the default branch is set in
> the same step and things can work out of the box after a small change on
> 'gh' that I will do as a next step.
I’m not totally opposed to this convenience, but couldn’t we also just teach gh to run set-head as a second command?
(Of course, it will need a version check; if memory serves not all Git versions used in practice have this command? But I am on mobile and have not validated the history of git-remote’s sub-commands.)
^ permalink raw reply
* [PATCH] remote: add --set-head option to 'git remote add'
From: Harald Nordgren via GitGitGadget @ 2026-04-25 11:19 UTC (permalink / raw)
To: git; +Cc: Harald Nordgren, Harald Nordgren
From: Harald Nordgren <haraldnordgren@gmail.com>
Mirror the behavior 'git clone' applies to its first remote: after
fetching, set refs/remotes/<name>/HEAD to the remote's default branch.
Equivalent to running:
git remote add -f <name> <url>
git remote set-head <name> -a
The new option implies --fetch.
Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
---
remote: add --set-head option to 'git remote add'
When using GitHub's gh tool to fork a repo, it seems that set-head isn't
run on the upstream remote. So its default branch is not recorded
locally, meaning that 'git log fork' will not work.
With git remote add --set-head upstream , the default branch is set in
the same step and things can work out of the box after a small change on
'gh' that I will do as a next step.
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2283%2FHaraldNordgren%2Fset_head-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2283/HaraldNordgren/set_head-v1
Pull-Request: https://github.com/git/git/pull/2283
Documentation/git-remote.adoc | 9 ++++++++-
builtin/remote.c | 26 ++++++++++++++++++++++++--
t/t5505-remote.sh | 8 ++++++++
3 files changed, 40 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-remote.adoc b/Documentation/git-remote.adoc
index eaae30aa88..0ef49c4164 100644
--- a/Documentation/git-remote.adoc
+++ b/Documentation/git-remote.adoc
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[synopsis]
git remote [-v | --verbose]
-git remote add [-t <branch>] [-m <master>] [-f] [--[no-]tags] [--mirror=(fetch|push)] <name> <URL>
+git remote add [-t <branch>] [-m <master>] [-f] [--set-head] [--[no-]tags] [--mirror=(fetch|push)] <name> <URL>
git remote rename [--[no-]progress] <old> <new>
git remote remove <name>
git remote set-head <name> (-a | --auto | -d | --delete | <branch>)
@@ -73,6 +73,13 @@ multiple branches without grabbing all branches.
With `-m <master>` option, a symbolic-ref `refs/remotes/<name>/HEAD` is set
up to point at remote's _<master>_ branch. See also the set-head command.
+
+With `--set-head` option, a symbolic-ref `refs/remotes/<name>/HEAD` is set
+up to point at the remote's default branch, mirroring the behavior of
+`git clone`. This is equivalent to running `git remote set-head <name> -a`
+after the remote is added, and implies `-f` so that the remote's refs are
+available locally. It cannot be combined with `-m <master>` or with a push
+mirror.
++
When a fetch mirror is created with `--mirror=fetch`, the refs will not
be stored in the `refs/remotes/` namespace, but rather everything in
`refs/` on the remote will be directly mirrored into `refs/` in the
diff --git a/builtin/remote.c b/builtin/remote.c
index de989ea3ba..8273b425a5 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -23,7 +23,7 @@
static const char * const builtin_remote_usage[] = {
"git remote [-v | --verbose]",
- N_("git remote add [-t <branch>] [-m <master>] [-f] [--tags | --no-tags] [--mirror=<fetch|push>] <name> <url>"),
+ N_("git remote add [-t <branch>] [-m <master>] [-f] [--set-head] [--tags | --no-tags] [--mirror=<fetch|push>] <name> <url>"),
N_("git remote rename [--[no-]progress] <old> <new>"),
N_("git remote remove <name>"),
N_("git remote set-head <name> (-a | --auto | -d | --delete | <branch>)"),
@@ -174,10 +174,21 @@ static int check_remote_collision(struct remote *remote, void *data)
return 0;
}
+static int set_head_auto_for_remote(const char *name)
+{
+ struct child_process cmd = CHILD_PROCESS_INIT;
+
+ strvec_pushl(&cmd.args, "remote", "set-head", "--auto", name, NULL);
+ cmd.git_cmd = 1;
+ if (run_command(&cmd))
+ return error(_("Could not set up HEAD for %s"), name);
+ return 0;
+}
+
static int add(int argc, const char **argv, const char *prefix,
struct repository *repo UNUSED)
{
- int fetch = 0, fetch_tags = TAGS_DEFAULT;
+ int fetch = 0, fetch_tags = TAGS_DEFAULT, set_head_auto = 0;
unsigned mirror = MIRROR_NONE;
struct string_list track = STRING_LIST_INIT_NODUP;
const char *master = NULL;
@@ -195,6 +206,8 @@ static int add(int argc, const char **argv, const char *prefix,
OPT_STRING_LIST('t', "track", &track, N_("branch"),
N_("branch(es) to track")),
OPT_STRING('m', "master", &master, N_("branch"), N_("master branch")),
+ OPT_BOOL(0, "set-head", &set_head_auto,
+ N_("set refs/remotes/<name>/HEAD according to remote (implies --fetch)")),
OPT_CALLBACK_F(0, "mirror", &mirror, "(push|fetch)",
N_("set up remote as a mirror to push to or fetch from"),
PARSE_OPT_OPTARG | PARSE_OPT_COMP_ARG, parse_mirror_opt),
@@ -211,6 +224,12 @@ static int add(int argc, const char **argv, const char *prefix,
die(_("specifying a master branch makes no sense with --mirror"));
if (mirror && !(mirror & MIRROR_FETCH) && track.nr)
die(_("specifying branches to track makes sense only with fetch mirrors"));
+ if (set_head_auto && master)
+ die(_("--set-head and --master are mutually exclusive"));
+ if (set_head_auto && mirror && !(mirror & MIRROR_FETCH))
+ die(_("--set-head makes no sense with a push mirror"));
+ if (set_head_auto)
+ fetch = 1;
name = argv[0];
url = argv[1];
@@ -269,6 +288,9 @@ static int add(int argc, const char **argv, const char *prefix,
result = error(_("Could not setup master '%s'"), master);
}
+ if (set_head_auto && set_head_auto_for_remote(name))
+ result = 1;
+
out:
strbuf_release(&buf);
strbuf_release(&buf2);
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index e592c0bcde..043c86315f 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -81,6 +81,14 @@ test_expect_success 'add another remote' '
)
'
+test_expect_success 'add remote with --set-head implies --fetch and sets HEAD' '
+ test_when_finished "git -C test remote remove third" &&
+ git -C test remote add --set-head third ../two &&
+ echo refs/remotes/third/main >expect &&
+ git -C test symbolic-ref refs/remotes/third/HEAD >actual &&
+ test_cmp expect actual
+'
+
test_expect_success 'setup bare clone for server' '
git clone --bare "file://$(pwd)/one" srv.bare &&
git -C srv.bare config --local uploadpack.allowfilter 1 &&
base-commit: 94f057755b7941b321fd11fec1b2e3ca5313a4e0
--
gitgitgadget
^ permalink raw reply related
* [PATCH v2 5/5] l10n: bump mshick/add-pr-comment from v2 to v3
From: Johannes Schindelin via GitGitGadget @ 2026-04-25 10:58 UTC (permalink / raw)
To: git; +Cc: Christoph Grüninger, Johannes Schindelin,
Johannes Schindelin
In-Reply-To: <pull.2097.v2.git.1777114720.gitgitgadget@gmail.com>
From: Johannes Schindelin <johannes.schindelin@gmx.de>
The l10n workflow uses `mshick/add-pr-comment` to post git-po-helper
reports as comments on translation pull requests. It was still pinned
to v2, which runs on Node.js 20. GitHub is phasing out the Node.js 20
runtime on Actions runners, so staying on v2 will eventually cause the
"Create comment in pull request for report" step to fail.
The sole breaking change in v3 is the switch from Node.js 20 to
Node.js 24 (https://github.com/mshick/add-pr-comment/releases/tag/v3.0.0).
The action's inputs and outputs are unchanged, so the upgrade is a
drop-in replacement. Subsequent v3.x releases added new opt-in
features (message truncation, retry with exponential backoff, file
attachments, commit comment support, "delete on status") but none of
them affect existing callers that do not opt in.
See also:
- Changelog: https://github.com/mshick/add-pr-comment/blob/main/CHANGELOG.md
- Compare: https://github.com/mshick/add-pr-comment/compare/v2...v3
Pointed-out-by: Christoph Grüninger <foss@grueninger.de>
Assisted-by: Claude Opus 4.6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
.github/workflows/l10n.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.github/workflows/l10n.yml b/.github/workflows/l10n.yml
index 95e55134bd..114a12a9e5 100644
--- a/.github/workflows/l10n.yml
+++ b/.github/workflows/l10n.yml
@@ -92,7 +92,7 @@ jobs:
cat git-po-helper.out
exit $exit_code
- name: Create comment in pull request for report
- uses: mshick/add-pr-comment@v2
+ uses: mshick/add-pr-comment@v3
if: >-
always() &&
github.event_name == 'pull_request_target' &&
--
gitgitgadget
^ permalink raw reply related
* [PATCH v2 4/5] ci: bump actions/checkout from v5 to v6
From: Johannes Schindelin via GitGitGadget @ 2026-04-25 10:58 UTC (permalink / raw)
To: git; +Cc: Christoph Grüninger, Johannes Schindelin,
Johannes Schindelin
In-Reply-To: <pull.2097.v2.git.1777114720.gitgitgadget@gmail.com>
From: Johannes Schindelin <johannes.schindelin@gmx.de>
Every workflow currently pins `actions/checkout` to v5, which was
introduced primarily to move to the Node.js 24 runtime. v6 is the
next release and worth picking up so we stay on a maintained version
of the action.
The one behaviorally interesting change in v6:
`persist-credentials` now stores the helper credentials under
`$RUNNER_TEMP` instead of writing them directly into the local
`.git/config`. Two implications follow:
1. In the normal case this is an unambiguous improvement -- the
token no longer lands in `.git/config`, reducing the risk of
inadvertently leaking it through workspace archiving
(`upload-artifact` snapshots, cache entries, core dumps, ...).
2. Docker container actions require an Actions Runner of at least
v2.329.0 to find the credentials in their new location. The
github.com-hosted runners our CI uses are already past that
version, so this does not affect us. Downstream users running
self-hosted runners may need to update them before adopting
this version of the action.
Risk analysis: our checkout steps either check out the default
repository (no special credential requirements) or, in the `vs-build`
job, explicitly set `repository: microsoft/vcpkg` and
`path: compat/vcbuild/vcpkg`. Neither case relies on the precise
location of the persisted credentials -- subsequent steps interact
with the API via the runner-provided `GITHUB_TOKEN` directly -- so
the v6 credential-storage change is transparent to our workflows.
The diff is purely the `@vN` identifier; there are no input or
output changes.
See also:
- Release notes: https://github.com/actions/checkout/releases
- Changelog: https://github.com/actions/checkout/blob/main/CHANGELOG.md
- Compare: https://github.com/actions/checkout/compare/v5...v6
Originally-authored-by: dependabot[bot] <support@github.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
.github/workflows/check-style.yml | 2 +-
.github/workflows/check-whitespace.yml | 2 +-
.github/workflows/coverity.yml | 2 +-
.github/workflows/main.yml | 24 ++++++++++++------------
4 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/.github/workflows/check-style.yml b/.github/workflows/check-style.yml
index 19a145d4ad..108a2de903 100644
--- a/.github/workflows/check-style.yml
+++ b/.github/workflows/check-style.yml
@@ -20,7 +20,7 @@ jobs:
jobname: ClangFormat
runs-on: ubuntu-latest
steps:
- - uses: actions/checkout@v5
+ - uses: actions/checkout@v6
with:
fetch-depth: 0
diff --git a/.github/workflows/check-whitespace.yml b/.github/workflows/check-whitespace.yml
index 928fd4cfe2..ea6f49f742 100644
--- a/.github/workflows/check-whitespace.yml
+++ b/.github/workflows/check-whitespace.yml
@@ -19,7 +19,7 @@ jobs:
check-whitespace:
runs-on: ubuntu-latest
steps:
- - uses: actions/checkout@v5
+ - uses: actions/checkout@v6
with:
fetch-depth: 0
diff --git a/.github/workflows/coverity.yml b/.github/workflows/coverity.yml
index 3435baeca2..89bef26727 100644
--- a/.github/workflows/coverity.yml
+++ b/.github/workflows/coverity.yml
@@ -38,7 +38,7 @@ jobs:
COVERITY_LANGUAGE: cxx
COVERITY_PLATFORM: overridden-below
steps:
- - uses: actions/checkout@v5
+ - uses: actions/checkout@v6
- name: install minimal Git for Windows SDK
if: contains(matrix.os, 'windows')
uses: git-for-windows/setup-git-for-windows-sdk@v1
diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index 6d7f26e71e..0ea266f27c 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -112,7 +112,7 @@ jobs:
group: windows-build-${{ github.ref }}
cancel-in-progress: ${{ needs.ci-config.outputs.skip_concurrent == 'yes' }}
steps:
- - uses: actions/checkout@v5
+ - uses: actions/checkout@v6
- uses: git-for-windows/setup-git-for-windows-sdk@v1
- name: build
shell: bash
@@ -173,10 +173,10 @@ jobs:
group: vs-build-${{ github.ref }}
cancel-in-progress: ${{ needs.ci-config.outputs.skip_concurrent == 'yes' }}
steps:
- - uses: actions/checkout@v5
+ - uses: actions/checkout@v6
- uses: git-for-windows/setup-git-for-windows-sdk@v1
- name: initialize vcpkg
- uses: actions/checkout@v5
+ uses: actions/checkout@v6
with:
repository: 'microsoft/vcpkg'
path: 'compat/vcbuild/vcpkg'
@@ -258,7 +258,7 @@ jobs:
group: windows-meson-build-${{ github.ref }}
cancel-in-progress: ${{ needs.ci-config.outputs.skip_concurrent == 'yes' }}
steps:
- - uses: actions/checkout@v5
+ - uses: actions/checkout@v6
- uses: actions/setup-python@v6
- name: Set up dependencies
shell: pwsh
@@ -286,7 +286,7 @@ jobs:
group: windows-meson-test-${{ matrix.nr }}-${{ github.ref }}
cancel-in-progress: ${{ needs.ci-config.outputs.skip_concurrent == 'yes' }}
steps:
- - uses: actions/checkout@v5
+ - uses: actions/checkout@v6
- uses: actions/setup-python@v6
- name: Set up dependencies
shell: pwsh
@@ -341,7 +341,7 @@ jobs:
TEST_OUTPUT_DIRECTORY: ${{github.workspace}}/t
runs-on: ${{matrix.vector.pool}}
steps:
- - uses: actions/checkout@v5
+ - uses: actions/checkout@v6
- run: ci/install-dependencies.sh
- run: ci/run-build-and-tests.sh
- name: print test failures
@@ -362,7 +362,7 @@ jobs:
CI_JOB_IMAGE: ubuntu-latest
runs-on: ubuntu-latest
steps:
- - uses: actions/checkout@v5
+ - uses: actions/checkout@v6
- run: ci/install-dependencies.sh
- run: ci/run-build-and-minimal-fuzzers.sh
dockerized:
@@ -439,7 +439,7 @@ jobs:
else
apt-get -q update && apt-get -q -y install git
fi
- - uses: actions/checkout@v5
+ - uses: actions/checkout@v6
- run: ci/install-dependencies.sh
- run: useradd builder --create-home
- run: chown -R builder .
@@ -464,7 +464,7 @@ jobs:
group: static-analysis-${{ github.ref }}
cancel-in-progress: ${{ needs.ci-config.outputs.skip_concurrent == 'yes' }}
steps:
- - uses: actions/checkout@v5
+ - uses: actions/checkout@v6
- run: ci/install-dependencies.sh
- run: ci/run-static-analysis.sh
- run: ci/check-directional-formatting.bash
@@ -480,7 +480,7 @@ jobs:
group: rust-analysis-${{ github.ref }}
cancel-in-progress: ${{ needs.ci-config.outputs.skip_concurrent == 'yes' }}
steps:
- - uses: actions/checkout@v5
+ - uses: actions/checkout@v6
- run: ci/install-dependencies.sh
- run: ci/run-rust-checks.sh
sparse:
@@ -494,7 +494,7 @@ jobs:
group: sparse-${{ github.ref }}
cancel-in-progress: ${{ needs.ci-config.outputs.skip_concurrent == 'yes' }}
steps:
- - uses: actions/checkout@v5
+ - uses: actions/checkout@v6
- name: Install other dependencies
run: ci/install-dependencies.sh
- run: make sparse
@@ -510,6 +510,6 @@ jobs:
CI_JOB_IMAGE: ubuntu-latest
runs-on: ubuntu-latest
steps:
- - uses: actions/checkout@v5
+ - uses: actions/checkout@v6
- run: ci/install-dependencies.sh
- run: ci/test-documentation.sh
--
gitgitgadget
^ permalink raw reply related
* [PATCH v2 3/5] ci: bump actions/github-script from v8 to v9
From: Johannes Schindelin via GitGitGadget @ 2026-04-25 10:58 UTC (permalink / raw)
To: git; +Cc: Christoph Grüninger, Johannes Schindelin,
Johannes Schindelin
In-Reply-To: <pull.2097.v2.git.1777114720.gitgitgadget@gmail.com>
From: Johannes Schindelin <johannes.schindelin@gmx.de>
The only use we have of `actions/github-script` is the "skip if the
commit or tree was already tested" step in `main.yml`, which checks
whether an identical tree-SHA was already built successfully. It
currently pins v8; v9 is the latest release.
What v9 changes:
- The `ACTIONS_ORCHESTRATION_ID` environment variable is now
appended to the HTTP user-agent string. This is transparent to
our script.
- A new injected `getOctokit` factory lets scripts create
additional authenticated clients in the same step without
importing `@actions/github`. We do not use it.
- Two breaking changes affect scripts that either call
`require('@actions/github')` (fails at runtime, because
`@actions/github` v9 is now ESM-only) or that shadow the
implicit `getOctokit` parameter via `const`/`let` (syntax
error). Our script does neither -- it only uses the pre-supplied
`github` REST client and `core` helpers -- so the upgrade is
safe.
Risk analysis: the step is advisory. It sets `enabled=' but skip'`
as an optimization to avoid re-running CI on a tree that was already
tested successfully. Even if the v9 upgrade broke the script, the
surrounding `try { ... } catch (e) { core.warning(e); }` block would
degrade it to a warning and CI would still run normally. In practice
the script continues to work identically on v9.
See also:
- Release notes: https://github.com/actions/github-script/releases
- Compare: https://github.com/actions/github-script/compare/v8...v9
Originally-authored-by: dependabot[bot] <support@github.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
.github/workflows/main.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index da31b10c79..6d7f26e71e 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -63,7 +63,7 @@ jobs:
echo "skip_concurrent=$skip_concurrent" >>$GITHUB_OUTPUT
- name: skip if the commit or tree was already tested
id: skip-if-redundant
- uses: actions/github-script@v8
+ uses: actions/github-script@v9
if: steps.check-ref.outputs.enabled == 'yes'
with:
github-token: ${{secrets.GITHUB_TOKEN}}
--
gitgitgadget
^ permalink raw reply related
* [PATCH v2 2/5] ci: bump actions/{upload,download}-artifact to v7 and v8
From: Johannes Schindelin via GitGitGadget @ 2026-04-25 10:58 UTC (permalink / raw)
To: git; +Cc: Christoph Grüninger, Johannes Schindelin,
Johannes Schindelin
In-Reply-To: <pull.2097.v2.git.1777114720.gitgitgadget@gmail.com>
From: Johannes Schindelin <johannes.schindelin@gmx.de>
`actions/upload-artifact` and `actions/download-artifact` are tightly
coupled: the upload action writes artifact archives in a format that
the download action then reads. Because of this coupling, the two
actions should always be bumped together so that the artifact format
contract between them is satisfied.
All of our `actions/upload-artifact` uses are still on v5, with one
stray v4 occurrence. Keeping them on these versions would leave the
artifact-upload steps running on Node.js 20, which GitHub is phasing
out, and would eventually cause all upload steps to fail.
Going from v5 directly to v7 folds in two release bumps:
- v6 switches the action's default runtime from Node.js 20 to
Node.js 24 (v5 had preliminary Node 24 support but still defaulted
to Node 20). This is the main motivation for bumping now: it gets
us off the deprecated runtime.
- v7 adds two opt-in features: direct (unzipped) single-file uploads
via a new `archive: false` parameter, and an internal conversion of
the action to ESM to match the updated `@actions/*` packages.
Risk analysis: we never pass `archive`, so the zip-as-usual behavior
is unchanged. We also do not `require('@actions/*')` from any calling
workflow, so the ESM migration cannot affect us. The upload steps we
care about -- tracked files/build artifacts and failing-test
directories -- keep the same inputs (`name`, `path`) and outputs, so
the diff is purely the `@vN` identifier. The main precondition is a
recent Actions Runner (>= 2.327.1), which the github.com-hosted
runners used by our CI already satisfy.
While at it, align the one remaining `@v4` occurrence with the rest
so that every `upload-artifact` step uses the same version.
See also:
- Release notes: https://github.com/actions/upload-artifact/releases
- Compare: https://github.com/actions/upload-artifact/compare/v5...v7
We use `actions/download-artifact` to pass build artifacts between
the "windows-build" / "vs-build" / "windows-meson-build" jobs and
their corresponding test jobs. All callers are currently on v6;
bumping to v8 keeps this action in lockstep with the `upload-artifact`
bump above.
What v7 and v8 change:
- v7 switches the default runtime from Node.js 20 to Node.js 24 (v6
had preliminary Node 24 support but still defaulted to Node 20).
This is the main motivation: it gets us off the deprecated runtime.
- v8 makes three further changes:
* The package is converted to ESM (invisible to workflow authors).
* The action now checks the `Content-Type` header before
attempting to unzip a download, so that directly-uploaded
(unzipped) artifacts from `upload-artifact` v7 are downloaded
correctly.
* The `digest-mismatch` behaviour is changed from warn-and-
continue to a hard failure by default.
Risk analysis: defaulting hash-mismatch to a hard failure is
strictly safer than the previous warn-and-continue behaviour -- a
mismatch points to real corruption or tampering and should stop the
run. We download archives that the same workflow just uploaded, on
the same runner fleet, so false positives are not expected. Our
usage is limited to the `name` and `path` inputs, which are
unchanged between v6 and v8, so the diff is purely the `@vN`
identifier.
See also:
- Release notes: https://github.com/actions/download-artifact/releases
- Compare: https://github.com/actions/download-artifact/compare/v6...v8
Originally-authored-by: dependabot[bot] <support@github.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
.github/workflows/main.yml | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index 0d3e0e42a4..da31b10c79 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -123,7 +123,7 @@ jobs:
- name: zip up tracked files
run: git archive -o artifacts/tracked.tar.gz HEAD
- name: upload tracked files and build artifacts
- uses: actions/upload-artifact@v5
+ uses: actions/upload-artifact@v7
with:
name: windows-artifacts
path: artifacts
@@ -140,7 +140,7 @@ jobs:
cancel-in-progress: ${{ needs.ci-config.outputs.skip_concurrent == 'yes' }}
steps:
- name: download tracked files and build artifacts
- uses: actions/download-artifact@v6
+ uses: actions/download-artifact@v8
with:
name: windows-artifacts
path: ${{github.workspace}}
@@ -157,7 +157,7 @@ jobs:
run: ci/print-test-failures.sh
- name: Upload failed tests' directories
if: failure() && env.FAILED_TEST_ARTIFACTS != ''
- uses: actions/upload-artifact@v5
+ uses: actions/upload-artifact@v7
with:
name: failed-tests-windows-${{ matrix.nr }}
path: ${{env.FAILED_TEST_ARTIFACTS}}
@@ -208,7 +208,7 @@ jobs:
- name: zip up tracked files
run: git archive -o artifacts/tracked.tar.gz HEAD
- name: upload tracked files and build artifacts
- uses: actions/upload-artifact@v5
+ uses: actions/upload-artifact@v7
with:
name: vs-artifacts
path: artifacts
@@ -226,7 +226,7 @@ jobs:
steps:
- uses: git-for-windows/setup-git-for-windows-sdk@v1
- name: download tracked files and build artifacts
- uses: actions/download-artifact@v6
+ uses: actions/download-artifact@v8
with:
name: vs-artifacts
path: ${{github.workspace}}
@@ -244,7 +244,7 @@ jobs:
run: ci/print-test-failures.sh
- name: Upload failed tests' directories
if: failure() && env.FAILED_TEST_ARTIFACTS != ''
- uses: actions/upload-artifact@v5
+ uses: actions/upload-artifact@v7
with:
name: failed-tests-windows-vs-${{ matrix.nr }}
path: ${{env.FAILED_TEST_ARTIFACTS}}
@@ -270,7 +270,7 @@ jobs:
shell: pwsh
run: meson compile -C build
- name: Upload build artifacts
- uses: actions/upload-artifact@v5
+ uses: actions/upload-artifact@v7
with:
name: windows-meson-artifacts
path: build
@@ -292,7 +292,7 @@ jobs:
shell: pwsh
run: pip install meson ninja
- name: Download build artifacts
- uses: actions/download-artifact@v6
+ uses: actions/download-artifact@v8
with:
name: windows-meson-artifacts
path: build
@@ -305,7 +305,7 @@ jobs:
run: ci/print-test-failures.sh
- name: Upload failed tests' directories
if: failure() && env.FAILED_TEST_ARTIFACTS != ''
- uses: actions/upload-artifact@v4
+ uses: actions/upload-artifact@v7
with:
name: failed-tests-windows-meson-${{ matrix.nr }}
path: ${{env.FAILED_TEST_ARTIFACTS}}
@@ -349,7 +349,7 @@ jobs:
run: ci/print-test-failures.sh
- name: Upload failed tests' directories
if: failure() && env.FAILED_TEST_ARTIFACTS != ''
- uses: actions/upload-artifact@v5
+ uses: actions/upload-artifact@v7
with:
name: failed-tests-${{matrix.vector.jobname}}
path: ${{env.FAILED_TEST_ARTIFACTS}}
@@ -449,7 +449,7 @@ jobs:
run: sudo --preserve-env --set-home --user=builder ci/print-test-failures.sh
- name: Upload failed tests' directories
if: failure() && env.FAILED_TEST_ARTIFACTS != ''
- uses: actions/upload-artifact@v5
+ uses: actions/upload-artifact@v7
with:
name: failed-tests-${{matrix.vector.jobname}}
path: ${{env.FAILED_TEST_ARTIFACTS}}
--
gitgitgadget
^ permalink raw reply related
* [PATCH v2 1/5] ci: bump microsoft/setup-msbuild from v2 to v3
From: Johannes Schindelin via GitGitGadget @ 2026-04-25 10:58 UTC (permalink / raw)
To: git; +Cc: Christoph Grüninger, Johannes Schindelin,
Johannes Schindelin
In-Reply-To: <pull.2097.v2.git.1777114720.gitgitgadget@gmail.com>
From: Johannes Schindelin <johannes.schindelin@gmx.de>
The v2 of `microsoft/setup-msbuild` runs on Node.js 20, which GitHub
is phasing out of the Actions runners. v3 is a minimal release whose
only substantive change is moving the action's runtime to Node.js 24,
so that our Visual Studio build jobs keep working once Node.js 20 is
removed from the runners.
The risk of this bump is very low: v3 contains no functional changes
to the action itself -- it merely adds `msbuild.exe` to `PATH`, with
no change to command-line flags, inputs, outputs, or default tool
resolution. The only precondition is a recent-enough Actions Runner,
which the github.com-hosted runners already satisfy.
See also:
- Release notes: https://github.com/microsoft/setup-msbuild/releases
- Compare: https://github.com/microsoft/setup-msbuild/compare/v2...v3
Originally-authored-by: dependabot[bot] <support@github.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
.github/workflows/main.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index 6f3d94e3a6..0d3e0e42a4 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -186,7 +186,7 @@ jobs:
repository: git/git
definitionId: 9
- name: add msbuild to PATH
- uses: microsoft/setup-msbuild@v2
+ uses: microsoft/setup-msbuild@v3
- name: copy dlls to root
shell: cmd
run: compat\vcbuild\vcpkg_copy_dlls.bat release
--
gitgitgadget
^ permalink raw reply related
* [PATCH v2 0/5] ci: GitHub Actions updates (brought to you by Dependabot)
From: Johannes Schindelin via GitGitGadget @ 2026-04-25 10:58 UTC (permalink / raw)
To: git; +Cc: Christoph Grüninger, Johannes Schindelin
In-Reply-To: <pull.2097.git.1776775319.gitgitgadget@gmail.com>
Dependabot (which my voice-typing software frequently mis-translates to "the
panda bot" 😉) is enabled in Git for Windows' fork of the git/git repository
to lighten the maintenance burden a little bit. Frequently, the updates are
not actually for Git for Windows' patches on top of git/git, but apply
directly to git/git.
Here is the latest batch of those updates, with heavily augmented commit
messages.
Changes since v1:
* Also bump mshick/add-pr-comment to the newest major version.
Johannes Schindelin (5):
ci: bump microsoft/setup-msbuild from v2 to v3
ci: bump actions/{upload,download}-artifact to v7 and v8
ci: bump actions/github-script from v8 to v9
ci: bump actions/checkout from v5 to v6
l10n: bump mshick/add-pr-comment from v2 to v3
.github/workflows/check-style.yml | 2 +-
.github/workflows/check-whitespace.yml | 2 +-
.github/workflows/coverity.yml | 2 +-
.github/workflows/l10n.yml | 2 +-
.github/workflows/main.yml | 50 +++++++++++++-------------
5 files changed, 29 insertions(+), 29 deletions(-)
base-commit: 94f057755b7941b321fd11fec1b2e3ca5313a4e0
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2097%2Fdscho%2Fdependabot-updates-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2097/dscho/dependabot-updates-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/2097
Range-diff vs v1:
1: 0d2fdc1cf4 = 1: 0d2fdc1cf4 ci: bump microsoft/setup-msbuild from v2 to v3
2: 5d719b3729 = 2: 5d719b3729 ci: bump actions/{upload,download}-artifact to v7 and v8
3: bfbe0db67f = 3: bfbe0db67f ci: bump actions/github-script from v8 to v9
4: 5694ca1016 = 4: 5694ca1016 ci: bump actions/checkout from v5 to v6
-: ---------- > 5: faa83723f4 l10n: bump mshick/add-pr-comment from v2 to v3
--
gitgitgadget
^ permalink raw reply
* Re: [PATCH] [ci] Update GitHub Actions to latest major release / GitHub #2278
From: Junio C Hamano @ 2026-04-25 10:37 UTC (permalink / raw)
To: Christoph Grüninger; +Cc: git, johannes.schindelin
In-Reply-To: <b3238847-91c1-42fa-b87a-b9d10daa6066@grueninger.de>
Christoph Grüninger <foss@grueninger.de> writes:
> Dear Git developer!
>
> I repost my suggested contribution from:
>
> https://github.com/git/git/pull/2278
Glad to see new people show interest in joining the Git development
community. Documentation/SubmittingPatches would help.
> I updated all GitHub Actions to their latest major release. In contrast
> to "ci: GitHub Actions updates" (brought to you by Dependabot
> (https://lore.kernel.org/git/pull.2097.git.1776775319.gitgitgadget@gmail.com/T/#t),
> I update some more standard actions and mshick/add-pr-comment.
> They fix deprecation warnings that GitHub Action deprecated Node20.js.
>
> Kind regards,
> Christoph
Thanks.
^ 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