Proposal: Add tip to use git update-git-for-windows when running git help or git version on Windows

Proposal: Add tip to use git update-git-for-windows when running git help or git version on Windows

[Aditya Garg]

I'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.

[PATCH] help: inform about 'git update-git-for-windows' on Windows

[Aditya Garg]

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

Re: [PATCH] help: inform about 'git update-git-for-windows' on Windows

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1272 bytes --]

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.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 325 bytes --]

Re: [PATCH] help: inform about 'git update-git-for-windows' on Windows

[Junio C Hamano]

"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.

Re: [PATCH] help: inform about 'git update-git-for-windows' on Windows

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2192 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 325 bytes --]

Re: [PATCH] help: inform about 'git update-git-for-windows' on Windows

[Aditya Garg]

> 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.