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.