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

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- 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 --]