threads / discuss / 63488
Subject: Proposal: Add tip to use git update-git-for-windows when running git help or git version on Windows
Aditya GargI've recently started exploring git for windows, and one thing I noticed was, there was no sign of updates! I googled a bit and found the git update-git-for-windows command. I think it would be nice if we could add a line like:
"Tip: Run `git update-git-for-windows` to update git"
At the last of the output when we run git help, git version or both.
Looking at the code, adding a compiler flag to check for windows in help.c and print it seems to be a possible solution.
Aditya Garg[PATCH] help: inform about 'git update-git-for-windows' on Windows
Not only there is a nice installer to install git on Windows, there is also a very nice command, git update-git-for-windows that makes updating git easy. But what I have noticed is that many people, which also included me, are not aware of this command.
Linux (and to some extend macOS) have awesome package managers, that can handle updates very well, but on Windows, the preferred way of installation remains using an installer.
Adding a little line indicating its existance and use while running git help should be nice way to inform users of the same. This commit exactly does that. git help should output the following on windows after this patch:
usage: git [-v | --version] [-h | --help] [-C <path>] [-c <name>=<value>]
[--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
[-p | --paginate | -P | --no-pager] [--no-replace-objects] [--no-lazy-fetch]
[--no-optional-locks] [--no-advice] [--bare] [--git-dir=<path>]
[--work-tree=<path>] [--namespace=<name>] [--config-env=<name>=<envvar>]
<command> [<args>]These are common Git commands used in various situations:
start a working area (see also: git help tutorial) clone Clone a repository into a new directory init Create an empty Git repository or reinitialize an existing one
work on the current change (see also: git help everyday) add Add file contents to the index mv Move or rename a file, a directory, or a symlink restore Restore working tree files rm Remove files from the working tree and from the index
examine the history and state (see also: git help revisions) bisect Use binary search to find the commit that introduced a bug diff Show changes between commits, commit and working tree, etc grep Print lines matching a pattern log Show commit logs show Show various types of objects status Show the working tree status
grow, mark and tweak your common history backfill Download missing objects in a partial clone branch List, create, or delete branches commit Record changes to the repository merge Join two or more development histories together rebase Reapply commits on top of another base tip reset Reset current HEAD to the specified state switch Switch branches tag Create, list, delete or verify a tag object signed with GPG
collaborate (see also: git help workflows) fetch Download objects and refs from another repository pull Fetch from and integrate with another repository or a local branch push Update remote refs along with associated objects
'git update-git-for-windows' can be used to update git.
'git help -a' and 'git help -g' list available subcommands and some concept guides. See 'git help <command>' or 'git help <concept>' to read about a specific subcommand or concept. See 'git help git' for an overview of the system.
Signed-off-by: Aditya Garg <gargaditya08@live.com> --- help.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/help.c b/help.c index 6ef90838f1..238ed1913c 100644 --- a/help.c +++ b/help.c @@ -355,6 +355,9 @@ void list_common_cmds_help(void) puts(_("These are common Git commands used in various situations:")); putchar('\n'); print_cmd_by_category(common_categories, NULL); +#ifdef _WIN32 + printf("\n'git update-git-for-windows' can be used to update git.\n"); +#endif } void list_all_main_cmds(struct string_list *list)
-- 2.43.0
brian m. carlsonRe: [PATCH] help: inform about 'git update-git-for-windows' on Windows
On 2025-05-21 at 14:22:29, Aditya Garg wrote:
> diff --git a/help.c b/help.c
> index 6ef90838f1..238ed1913c 100644
> --- a/help.c
> +++ b/help.c
> @@ -355,6 +355,9 @@ void list_common_cmds_help(void)
> puts(_("These are common Git commands used in various situations:"));
> putchar('\n');
> print_cmd_by_category(common_categories, NULL);
> +#ifdef _WIN32
> + printf("\n'git update-git-for-windows' can be used to update git.\n");
> +#endifI don't think this belongs in our codebase. It should instead be carried as a patch in Git for Windows. The reason is that there are a variety of possible projects that compile for Windows—Git for Windows, Cygwin, MINGW, etc.—and only one of them ships this binary. It is even possible for users to compile their own Windows binaries, which I know is at least done by Microsoft as well as some Git contributors on Windows.
This change might be misleading or incorrect as it might tell users to invoke a binary which is not present or to update software in a way which is not via the normal package mechanism. For instance, telling a MINGW or Cygwin user to run that command would not result in anything useful or desired happening.
-- brian m. carlson (they/them) Toronto, Ontario, CA
Junio C HamanoRe: [PATCH] help: inform about 'git update-git-for-windows' on Windows
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
> On 2025-05-21 at 14:22:29, Aditya Garg wrote:
>> diff --git a/help.c b/help.c
>> index 6ef90838f1..238ed1913c 100644
>> --- a/help.c
>> +++ b/help.c
>> @@ -355,6 +355,9 @@ void list_common_cmds_help(void)
>> puts(_("These are common Git commands used in various situations:"));
>> putchar('\n');
>> print_cmd_by_category(common_categories, NULL);
>> +#ifdef _WIN32
>> + printf("\n'git update-git-for-windows' can be used to update git.\n");
>> +#endif
>
> I don't think this belongs in our codebase. It should instead be
> carried as a patch in Git for Windows. The reason is that there are a
> variety of possible projects that compile for Windows—Git for Windows,
> Cygwin, MINGW, etc.—and only one of them ships this binary. It is even
> possible for users to compile their own Windows binaries, which I know
> is at least done by Microsoft as well as some Git contributors on
> Windows.
>
> This change might be misleading or incorrect as it might tell users to
> invoke a binary which is not present or to update software in a way
> which is not via the normal package mechanism. For instance, telling a
> MINGW or Cygwin user to run that command would not result in anything
> useful or desired happening.Do you mean that this is OK if the #ifdef were more specific to Git-for-Windows? Just being curious.
brian m. carlsonRe: [PATCH] help: inform about 'git update-git-for-windows' on Windows
On 2025-05-21 at 22:23:33, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes: > > I don't think this belongs in our codebase. It should instead be > > carried as a patch in Git for Windows. The reason is that there are a > > variety of possible projects that compile for Windows—Git for Windows, > > Cygwin, MINGW, etc.—and only one of them ships this binary. It is even > > possible for users to compile their own Windows binaries, which I know > > is at least done by Microsoft as well as some Git contributors on > > Windows. > > > > This change might be misleading or incorrect as it might tell users to > > invoke a binary which is not present or to update software in a way > > which is not via the normal package mechanism. For instance, telling a > > MINGW or Cygwin user to run that command would not result in anything > > useful or desired happening. > > Do you mean that this is OK if the #ifdef were more specific to > Git-for-Windows? Just being curious.
I don't think that would be a good idea, either. There's no such #ifdef to my knowledge and we have lots of ways for people to update software. We don't tell people to run commands to update to a newer version of their Debian package because that's a responsibility of the packager or distributor, and so the same policy applies here. If Debian wants that message to be included, then they can apply a patch and receive any bug reports or other feedback related to that message; same goes for Git for Windows.
I also happen to know that in some corporate environments proxy problems cause the updater to break (which is not in any way a surprise) and there are also cases where antivirus false positives flag the updater or other tools. We do not in any way want to receive reports about those problems or the updater and if we avoid recommending it, then we aren't responsible for it. Otherwise, we'll inevitably get a request to allow people to configure that message because it doesn't work in their very special corporate environment and they don't want to confuse their users.
-- brian m. carlson (they/them) Toronto, Ontario, CA
Aditya GargRe: [PATCH] help: inform about 'git update-git-for-windows' on Windows
> On 22 May 2025, at 4:31 AM, brian m. carlson <sandals@crustytoothpaste.net> wrote: > > On 2025-05-21 at 22:23:33, Junio C Hamano wrote: >> "brian m. carlson" <sandals@crustytoothpaste.net> writes: >>> I don't think this belongs in our codebase. It should instead be >>> carried as a patch in Git for Windows. The reason is that there are a >>> variety of possible projects that compile for Windows—Git for Windows, >>> Cygwin, MINGW, etc.—and only one of them ships this binary. It is even >>> possible for users to compile their own Windows binaries, which I know >>> is at least done by Microsoft as well as some Git contributors on >>> Windows. >>> >>> This change might be misleading or incorrect as it might tell users to >>> invoke a binary which is not present or to update software in a way >>> which is not via the normal package mechanism. For instance, telling a >>> MINGW or Cygwin user to run that command would not result in anything >>> useful or desired happening. >> >> Do you mean that this is OK if the #ifdef were more specific to >> Git-for-Windows? Just being curious. > > I don't think that would be a good idea, either. There's no such #ifdef > to my knowledge and we have lots of ways for people to update software. > We don't tell people to run commands to update to a newer version of > their Debian package because that's a responsibility of the packager or > distributor, and so the same policy applies here. If Debian wants that > message to be included, then they can apply a patch and receive any bug > reports or other feedback related to that message; same goes for Git for > Windows. > > I also happen to know that in some corporate environments proxy problems > cause the updater to break (which is not in any way a surprise) and > there are also cases where antivirus false positives flag the updater or > other tools. We do not in any way want to receive reports about those > problems or the updater and if we avoid recommending it, then we aren't > responsible for it. Otherwise, we'll inevitably get a request to allow > people to configure that message because it doesn't work in their very > special corporate environment and they don't want to confuse their > users.
Makes sense, let's just drop this patch then.