I've used it at work. But the manual management/maintenance of a commit list makes it practically infeasible. I've use it for bit cleanup commits, but not since. When blaming, the previous revision is just one click away anyway. The maintenance doesn't seem worth the effort.
I guess a commit message tag and script that generates it automatically could make it viable. But I've not found the need to yet.
Given that it is high level, I assume you did not want to include this. I'll mention it here in a comment either way. Text form in the commit message.
I really like using conventional commit messages and introduced it in my projects. We defined a few types, and more leniently choose optional scopes. It's very useful for categorizing and skimming through commit lists, and for generating changelogs/release notes. `fix(account): Use correct hasing xy"
Consistent imperative form is important to me too. The commit message examples talks about "Summary of changes", which has no verb, and so, may mislead to a different undesirable form of summarizing changes. ("Change xy" instead of "changed xy" or "[now] does xy [at runtime]" or "did z".)
I didn't fully read it, only skimmed, so excuse me if I missed mentions of the commit message text form. It seems very elaborate otherwise.
My browser has a default font size of 18 set. The site overrides that with a default base font size of 12px, then increases it to 13px for content text. That's way too small for me on my screen. At least to read it comfortably. Or for people who need more accessible text/font.
Are you sure? I'm not very active in that ecosystem, but if that was prevalent in the past, surely there's still tutorials and stuff out there that people would follow and create such projects even today?
The problem was named after an incident in 1996 in which AOL's profanity filter prevented residents of the town of Scunthorpe, North Lincolnshire, England, from creating accounts with AOL, because the town's name contains the substring "cunt".
Responsibility is shared. It's not one or the other.
Many people don't know what they're doing. That's kind of expected. But a tool provider and seller should know what they're doing. Enabling people to behave in a negative way should be questioned. Maybe it's a consequence of enablement, or maybe it's bad design or marketing. Where criticism is certainly warranted.
Notably for CPU only. And on other platforms they already did.
Broadcom would like to clarify that while using KVM for the CPU virtualization, they will continue to rely on all of the existing VMware virtual devices for graphics and other functionality. Also on both macOS and Windows they have migrated to the native CPU virtualization frameworks.
I found it hard to follow despite C# being my main driver.
Using ref, in the past, has been about modifiable variable references.
All these introductions, even when following C# changes across recent versions, were never something I actively used, apart from the occasional adding ref to structs so they can contain existing ref struct types. It never seems necessary.
Even without ref you use reference and struct types, where reference content can be modified elsewhere. And IDisposable for object lifetimes with cleanup.
It's not a must [unless you put it into a contract], it's a should or would be nice
Many, if not most, projects don't follow a good, obvious, transparent, documented release or change management.
I wish for it, too, but it's not the reality of projects. Most people don't seem to care about it as much as I do.
I agree blind acceptance/merging is problematic. But for some projects (small scope/size/personal-FOSS, trustworthy upstream) I see it as pragmatic rather than problematic.
