> On 22 May 2025, at 4:31 AM, brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > > On 2025-05-21 at 22:23:33, Junio C Hamano wrote: >> "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> 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.
