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

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: May 21, 2025, 23:00 UTC
Message-ID: <aC5bI_Y9-ZQPXJ4t@tapette.crustytoothpaste.net>
In-Reply-To: <xmqq5xht8uxm.fsf@gitster.g>

On 2025-05-21 at 22:23:33, Junio C Hamano wrote:

Show 17 quoted lines

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