Re: [PATCH v2 00/12] fsmonitor: Implement fsmonitor for Linux

[Junio C Hamano <gitster@pobox.com>]

Glen Choo <chooglen@google.com> writes:

> At $DAYJOB, we observed that this topic breaks MacOS builds with sha1dc:

Thanks for a report.

How dissapointing.  The thing is that the topic has been in 'next'
since the 11th (i.e. early last week), and I know that you guys rely
on the tip of 'next' in working order to cut your internal releases,
but we did not hear about this until now.  What makes it taste even
worse is that nobody else caught this, even though we seem to have a
couple of macOS jobs at GitHub Actions CI, there we didn't see any
breakage related to this.

Possible action items:

 * See what configurations our two macOS jobs are using.  If neither
   is using sha1dc, I would say that is criminal [*] and at least
   one of them should be updated to do so right away.

 * The "two macOS CI jobs sharing too many configuration knobs" may
   not be limited to just SHA-1 implementation, but unlike Linux
   builds and tests, we may have similar "monoculture" issue in our
   macOS CI builds.  Those users, who depend on macOS port being
   healthy, should help identify unnecessary overlaps between the
   two, and more importantly, make sure we have CI builds with
   configuration similar to what they actually use.

 * Adding a few build-only-without-tests CI jobs also might help.

 * Those who depend on working macOS port, especially those with
   corporate backing who choose to use configurations that are
   different from what we have CI builds for, are requested to
   arrange a more frequent build test to catch a problem like this
   much earlier.

Anything else I forgot that we can do to improve the situation?  I
personally do not use macOS, I am not interested in using one, but
I do value those who choose to use macOS have happy git working on
their platform, so the stakeholders need to chip in.

Thanks.


[Footnote]

 * Until the world migrates over to SHA-256, the collision detecting
   SHA-1 implementation is what we must use unless there is a strong
   reason not to.  If we are not testing something that ought to be
   the default, we are not doing a very good job.