I think nobody talks about it because it doesn’t show history

What do you mean it doesn't show history? It's perhaps the only thing it handles better than most third-party git GUIs.

It’s not and no one cares about numbers anymore.

The only people who ever cared about svn's numbering scheme were those who abused it as a proxy to release/build versions, which was blaming the tools for the problems they created for themselves.

Sure if you never branch, which is a severely limited way of using git.

It's quite possible to use Git without creating branches. Services like GitHub can automatically create feature branches for you as part of their ticket-management workflow. With those tools, you start to work on a ticket, you fetch the repo, and a fancy branch is already there for you to use.

You also don't merge branches because that happens when you click on a button on a PR.

Logging in local time is fine as long as the offset is marked.

I get your point, but that's just UTC with extra steps. I feel that there's no valid justification for using two entries instead of just one.

I’ve had mixed results with ccache myself, ending up not using it.

Which problems did you experienced?

Compilation times are much less of a problem for me than they were before, because of the increases in processor power and number of threads.

To each its own, but with C++ projects the only way to not stumble upon lengthy build times is by only working with trivial projects. Incremental builds help blunt the pain but that only goes so far.

This together with pchs (...)

This might be the reason ccache only went so far in your projects. Precompiled headers either prevent ccache from working, or require additional tweaks to get around them.

https://ccache.dev/manual/4.9.1.html#_precompiled_headers

Also noteworthy, msvc doesn't play well with ccache. Details are fuzzy, but I think msvc supports building multiple source files with a single invocation, which prevents ccache to map an input to an output object file.

You'd be missing the whole point too if you think that the pointer is the root cause. The problem is that the class is not designed to be copy-able, let alone moveable. Your suggestion to use a unique_ptr will also blow up in your face the moment you try to copy an instance.

Simply taking std::string by value (as it is a memory management class created for that explicit purpose) would have solved the problem without kneecapping every class you make.

I think you are missing the whole point.

The blogger tried to make a point about how special member functions can be tricky to get right if you don't master them. In this case, the blogger even presents a concrete example of how the rule of 3/rule of 5 would fail to catch this issue. As the blogger was relying on the implicit special member functions to manage the life cycle of CheeseShop::clerkName and was oblivious to the possibility of copying values around, this resulted in the double free.

You can argue that you wouldn't have a problem if the string was used instead of a pointer to string, which is a point that the blogger indirectly does, but that would mean you'd be missing the root cause and missing the bigger picture, as you'd be trusting things to work by coincidence instead of actually knowing how they work.

The blogger also does a piss-poor job in advocating to explicitly delete move constructors, as that suggests he learned nothing from the ordeal. A preferable lesson would be to a) not use raw pointers and instead try to adopt a smart pointer with the relevant semantics, b) actually provide custom implementations for copy/move constructors/assignment operators whenever doing anything non-trivial to manage resources, such as handling raw pointers and needing to both copy them and free them whenever they stop being used.

The Philosophy section has quite a few wonky arguments; I’d skip it altogether.

I agree. I wish they moved that to a standalone section so that it could be easily skipable. Reference docs can and should have a rationale, but a lengthy rant is not what leads people to the site.

As a side note, the final keyword is only tangentially related with inlining. It's killer feature is removing the need to do pointer dereferencing when calling virtual members of instances of classes that no longer require virtualization.

Fair enough.

Because you’d have to stash your modifications to be able to switch branch.

OP said nothing about stashing, only committing WIP commits to feature branches. I don't think none of your remarks apply, because if you really need stuff from the WIP commits you can also cherry-pick them or checkout specific files.

When you have 1000+ Cypress tests, for example, it takes time to run, plain and simple.

It's one thing to claim that tests need time to run.

It's an entirely different thing to claim that the time it takes to run tests is proportional to test coverage.

More often than not, you have massively expensive and naive test fixtures in place that act as performance boat anchors and are massive bottlenecks. Thousands of tests run instantly if each test takes around a few milliseconds to run. For perspective, the round trip of network request that crosses the world is around a couple of hundreds of milliseconds. A thousand of sequential requests takes only a couple of minutes. If each of your tests takes that long to run, your tests are fundamentally broken.