Re: lots of fatal build system bugs on OpenBSD

[Ingo Schwarze]

Hi Doug,

Douglas McIlroy wrote on Tue, Mar 22, 2022 at 08:58:19AM -0400:

> Tangential comment:
> I have always recoiled from git.

I agree to some extent.  Git does get a number of things right, but
there are also many aspects of its user interface and design that make
it harder to use than necessary.  It's hard to call those issues fatal
though because git is so configurable that you can configure away almost
anything you dislike - *if* you figure out what you need to configure
away and how that works, which can occasionally take quite some time.
It is certainly suffering from some overengineering and even more from
rampant featuritis and an overall design that is in some aspects more
labyrinthine than cleanly layered and cleanly modularized...

> The appearance of "diff --git" in Ingo's  post reinforced my
> aversion..

Yes, a few years ago diffs prepared with git(1) and submitted
to OpenBSD caused so many subtle problems that a general rule
was made that creating diffs with git(1) is strictly forbidden
and most developers rejected diffs created with git(1) without
even looking at them.

But it's an uphill battle.  The popularity of git(1) keeps constantly
growing and it has become so popular even with a sizeable fraction of
OpenBSD developers that banning it outright is no longer tenable.

Besides, it is the SCM officially chosen for the GNU troff project
years ago, and that's why i am using it to send diffs to this list.

Arguably, in spite of all its bloat, it might still be on par,
or likely even batter than, most other distributed SCMs...

> --git is not mentioned in any
> documentation (man or texinfo) I could get my hands on.

In fact, it doesn't even work:

  schwarze@isnote $ gdiff --version
  diff (GNU diffutils) 3.8
  Copyright (C) 2021 Free Software Foundation, Inc.
  schwarze@isnote $ gdiff --git /dev/null /dev/null
  gdiff: unknown option -- git
  gdiff: Try 'gdiff --help' for more information.

It is documented in the git-diff(1) manual page below "GENERATING PATCH
TEXT WITH -P".  The text is vague though and doesn't really explain what
the "--git" option is supposed to mean.  Maybe just "This diff was
created with git(1) and may contain some syntax that plain patch(1)
does not fully understand."

> Gnu diff's 100-line help message is depressing enough even without
> --git. Where did --git come from and what special pleading justifies
> it?

To be fair, the diff(1) help message is depressing even in a system
like OpenBSD:

  schwarze@isnote $ diff -y
  diff: unknown option -- y
  usage: diff [-abdipTtw] [-c | -e | -f | -n | -q | -u] [-I pattern]
              [-L label] file1 file2
         diff [-abdipTtw] [-I pattern] [-L label] -C number file1 file2
         diff [-abditw] [-I pattern] -D string file1 file2
         diff [-abdipTtw] [-I pattern] [-L label] -U number file1 file2
         diff [-abdiNPprsTtw] [-c | -e | -f | -n | -q | -u] [-I pattern]
              [-L label] [-S name] [-X file] [-x pattern] dir1 dir2

or even in something ancient and bare-bony like Solaris 9:

  schwarze@unstable9s :~ > diff -y          
  diff: illegal option -- y
  usage: diff [-bitw] [-c | -e | -f | -h | -n | -u] file1 file2
         diff [-bitw] [-C number | -U number] file1 file2
         diff [-bitw] [-D string] file1 file2
         diff [-bitw] [-c | -e | -f | -h | -n | -u] [-l] [-r] [-s]
              [-S name] directory1 directory2

Then again, extending this *a bit* maybe wasn't a bad idea;
for example, unified diffs *are* useful:

  schwarze@isnote $ man -hM /co/v7/usr/man diff
  diff [ -efbh ] file1 file2

Yours,
  Ingo

P.S.
Oops, getting into an SCM war is probably a bad idea, sorry for that.