Re: [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.