Indeed. Back in 2018 and 2019 I expended a fair amount of time and energy reporting a squash 'n' merge metadata rewriting bug to GitHub and advocating for the behaviour to be changed. [1]
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.
> I think even the development system wasn't free either.
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.
Wikipedia says "ISO 8601:2004 established a reference calendar date of 20 May 1875 (the date the Metre Convention was signed), later omitted from ISO 8601-1:2019." I was curious what "reference calendar date" is supposed to mean.
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.
I'm another one who's had two colonoscopies. Try to schedule it for the morning so that most of the fasting time will be while you're asleep. The prep is not a lot of fun, but it's only about half a day and it's very much not as bad as gastroenteritis or anything else that'll give you a good bout of diarrhoea.
As noted above, what used to be a cool little Wellington-based company got bought by some offshore conglomerate. Lenz himself left about five years ago.
Probably the older email address is still the primary one for the GitHub account.
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.
Handy, but is it really easier to type? Or as pleasantly reminiscent of one of the first Unix commands you ever learnt, back in the days when they actually really were multiuser machines? :-)
That is a nice trick. I've had my main email address in .config/git/config, added an override in ./.git/config for projects that need it, and checked who I am from time to time with
Having said that, given that many people do use separate GitHub accounts for their separate private and work personas, and many organisations seemingly expect their employees to do so, perhaps GitHub could consider revising this Terms of Service restriction to better reflect reality.
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>.)
> 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.
Various government departments of those countries use domains under .gouv.fr, .gob.es, .gov.ro respectively. The argument is that fairness and clarity would suggest that the US likewise use .gov.us or some other convention of their choice under .us.
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.
Export $BASH_SILENCE_DEPRECATION_WARNING as described in the Apple web page pointed to by the nag message, or change your shell to your own version of Bash.
Zlib-ng doesn't contain the same code, but it appears that their equivalent inflate() when used with their inflateGetHeader() implementation was affected by a similar problem: https://github.com/zlib-ng/zlib-ng/pull/1328
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.
Prior to 1.2.13 released a few days ago, neither of these commits was contained in a zlib release. The CVE exists in the state of the code prior to that first commit, and is fairly obvious when you read the explanation in the commit message. The first commit fixed the CVE but introduced a silly null pointer deference, which was quickly fixed by the second commit and never appeared in a release.
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.)
I too was surprised to see these were shell scripts. I was expecting the grep/fgrep/egrep names to be hard links to the same executable that would check `argv[0]`, as the BSD implementation does.
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
Looking at the linked script, it indicates which cow orker to credit.
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?
The scheme proposed in TFA is not particularly amenable to automation:
> 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.
This is nice in theory, but it will inevitably get screwed up by your less details-oriented coworkers.
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.)
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