Once or twice someone internal to GitHub got interested... and then drifted away again. Years later the broken behaviour remains. And I'm a lot more cynical about thinking GitHub fundamentals might ever get any better.

[1] https://github.com/isaacs/github/issues/1368

Metrowerks CodeWarrior was the original development system for PalmOS and was indeed not free (in either sense).

However a bunch of enthusiasts cobbled together some free development tools: the main parts were adapting the GCC and binutils m68k targets to PalmOS's constrained PIC runtime environment (it was constrained even by m68k standards); a tool to convert the resulting COFF or ELF executable to PalmOS's .prc database format; and a text-based resource compiler for generating UI elements using its own home-grown description language to express what CodeWarrior users were using a graphical UI editor to make.

That mostly still exists as it was back in the PalmOS days at <https://prc-tools.sourceforge.net>. And if you hunt around on GitHub you'll find a few people who've kept the code compiling with stricter more modern compilers.

(And see also <https://pilrc.sourceforge.net> for the resource compiler.)

Thanks to links in the SE thread, I found the relevant actual text in ISO 8601:2000 (I don't know how different it might be, if at all, in the 2004 document):

> The Gregorian calendar provides a reference system consisting of a, potentially infinite, series of contiguous calendar years. Consecutive calendar years are identified by sequentially assigned year numbers. A reference point is used which assigns the year number 1875 to the calendar year in which the “Convention du mètre” was signed at Paris.

This last sentence is simply an obtuse way to say "this year right now, as I [jomar] write this -- we call this 2025". Apparently the ISO committee did not want to refer to what was going on around 1 AD or felt that the missing 0 between 1 BC and 1 AD would lead to confusion or something, so instead used the birth year of the metre to state the bleeding obvious.

GitHub took it upon themselves to change email addresses and author names when merging via the UI buttons like "Squash and Merge" in 2018 and then again in 2019. See <https://github.com/isaacs/github/issues/1368> for the tedious details.

Essentially the post-2019 behaviour seems to be that where possible with "Squash and Merge" they will set noreply@github as the committer so that they can sign the merged commit themselves, and set author name & email to what they have recorded for the GH account involved (and the signature is then a record that GH have verified that account's involvement).

Personally I think it is shocking that they ignore the name and email address that the actual author of the commit has selected. This is both a violation of the author's intentions -- for example, you may set work and personal email addresses in different repositories as discussed here, but GitHub will rewrite them all to the same thing when other people press "Squash and Merge" on your pull requests -- and potentially a doxxing security risk.

I have considered re-reporting this to GitHub via the newer community discussions or via support again, but given the extent to which they've ignored all such reports over the last five years it is hard to find the motivation to do so.

    [alias]
        whoami = "!f() { echo $(git config --get user.name)' <'$(git config --get user.email)'>'; }; f"

There have also been times when I would like to have access to a second GitHub account for testing purposes. (In particular, for testing GH behaviour when the accounts corresponding to PR commits, PR creator, and PR merger all differ -- see for example <https://github.com/isaacs/github/issues/1368>.)

The third bullet point at https://docs.github.com/en/site-policy/github-terms/github-t... --

> One person or legal entity may maintain no more than one free Account (if you choose to control a machine account as well, that's fine, but it can only be used for running a machine).

This is the primary reason why I have only ever used my own personal account for work stored at GitHub. If a company is expecting its employees to use a separate work GH account, one assumes that company is planning to pay for all those accounts for its employees.

For how many decades is this going to be a reasonable argument?

In 100 years, will it still be reasonable for the USA to say "we built the thing, so it is appropriate for us to continue to be the default country in domain names. The rest of you must use your ccTLDs, but we remain special."

In 200 years?

The only non-pathetic option is for the United States to transition to using its .us ccTLD for governmental and military domains in particular, with .edu and probably some others not far behind. The only question is how gradual the process is, and when it starts.

See also <https://apple.stackexchange.com/questions/371997/suppressing...>. I went with the "use an updated brewed Bash" approach, which has been working well. Using `sudo chfn` means you don't need to futz around with editing /etc/shells.

Also similarly, most client code will be unaffected because `state->head` will be NULL, because they (most client code) won't have used inflateGetHeader() at all.

Studying the code it's easy to convince yourself that the CVE description is correct and client code that does not use inflateGetHeader() is entirely immune to the CVE. Searching GitHub suggests that use of this function is uncommon, and certainly it's not used by any of the client code that I checked for potential vulnerability to this CVE. So all the client code that I checked was unaffected by this CVE.

Hence IMHO this particular CVE is not really a big deal, because very little client software uses the somewhat obscure inflateGetHeader() API function. I suspect this is why the zlib maintainers didn't seem to be in a particular hurry to get this release out, after the CVE was made public in at least August or early September and they had already fixed it in early August. (Me, I became aware of it in early September, so the vulnerability was publicly disclosed at least by then.)

More interesting than the commit diff is the brief discussion on the bug report from when this all happened a year ago, as referenced in the commit message: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49996

Sigh. Time to retrain the old fingers again...

To the OP: You might be able to simplify the script by using `git commit --trailer …`. Or maybe you tried that and it didn't display the message in the editor window satisfactorily?

> Can I programatically convert from what I use now?

> Unfortunately, probably not

Moreover, even if a syntax-aware formatter could detect mistakes made in following this scheme, that presupposes that these coworkers will actually use said tools.

Some of us work in organisations where it is not politically feasible to insist that everyone work in any particular way or adhere to any particular standards. Welcome to academia…

Or just consider whether everyone contributing PRs to an open source project will get this right or use such tools.

The spaces and tabs are mostly invisible, so even if they did care about it these people can't really see the conventions that are in use. So the source code will inevitably accrue indentation done via spaces mixed up with the good lines indented via tabs, and then it's game over.

A script I have been working on lately is mostly tab-indented but has space-indented tracts and individual lines mixed in as it has been worked on by multiple authors over the years. When I started working on it, I thought the indentation was just plain borked (with the subclauses of if statements indented less than their if lines, etc). But then I discovered that setting tabstop=2 made most of the space-indented lines line up properly -- turns out this script was written to a 2-space indent (crazy narrow by my standards!) using tabs, with a few space-indented lines mixed in on the same scheme. Until another author came along some years ago with their tabs set to 4, and added some space-indented lines written to line up with the 4-space tabs they were looking at. So now there are several incompatible categories of space-indented lines in this 200 line source file.

The real argument from the spaces camp is that their approach is the only realistic compromise with reality: by banning explicit tab characters in source files on disk, there is no room for error.

(Except that the same coworkers are wont to include trailing whitespace or omit the final newline, but at least that sort of invisible difference does not affect reading the indentation.)