I mean, I've been doing this for over a decade too. If teams are losing data from their issue tracker or source forge, that's a deep problem and not something that can be ameliorated by writing better commit messages.
BatmanAoD
joined 1 year ago
The gitlog is intended for contributors of the project whereas the chamgelog is intended for users of the project.
That makes sense to me.
I think I would still argue, however, that for projects using github, gitlab, or any similar forge with a built-in pull-request + code-review feature, there's very limited value in spending time crafting good commit messages in a feature branch. All information that you may be tempted to put there would be more visible and more useful either as code comments (which applies to all projects, not just GH) or as comments in the PR description or discussion. (I also think it's often better to just squash feature branches on merge than to try to maintain a clean branch history while the feature is in development.)
I do think that the commit messages that actually end up on your trunk are important; but, with the exception of the final PR merge (or squash) commit, developers should minimize the time spent writing or thinking about these commit messages.
The one context in which I find details in historical commit messages potentially useful is when using git log -p to figure out when and why something changed. But even then, once I've found the relevant commit, looking up the PR to see if there was any discussion about the change in question is generally the next step; so again, having substantial detail in the commit message itself is unlikely to be helpful.
Why should I put manual effort into separately maintaining a changelog and a semantically meaningful commit history? If I'm going to manually maintain atomic commits with useful commit messages, why would I want the contents of those messages to be substantially different from the content of the relevant bullets of the changelog?
The O'Reilly book Programming Rust is very much targeted at C++ users, even if it isn't explicitly marketed that way.
I read the first edition, which predated async Rust, so I can't comment on how the second edition handles that topic. But the handling of everything else was, I think, excellent.
Yes, using Windows apps (beyond very simple things like the file manager) to deal with WSL resources, or vice-versa, is generally a bad time; WSL only really shines if you treat it like a separate computer, i.e. a Linux server you have access to. (This is exactly how VSCode's WSL extension does in fact operate.)
And yeah, if I had been given the choice, I definitely would have gone back to native Linux rather than stuck with Windows during the years I used WSL as my daily driver. But that would have been an uphill battle against IT that I wasn't interested in fighting, and I preferred WSL+Windows to MacOS. (Now that I've got an ARM Mac, the hardware advantage is sufficient that I probably wouldn't go back to WSL any time soon, but I still miss having a genuine Linux kernel without needing to run VirtualBox or something.)
🤷 That wasn't my experience, and I used it as my primary dev environment for four years.
It doesn't go through a translation layer, though. WSL 2 has a whole separate kernel. You can even use GUI apps with Wayland.
For what it's worth, WSL 2 with VSCode is actually great. Almost all the benefits of Linux (I still miss true tiling window management), with fewer weird driver issues.
That said, I generally just use whatever my company wants me to use, and I haven't worked somewhere that let us use native Linux boxes since 2014.
Modev says they've been using C for 25 years, and used Rust for several years as well! Their whole schtick baffles me.
I also hope that some of the people reading this realize that OP is also the person posting all of the "stop trying to suppress C" posts.
So...is snac.bsd.cafe entirely C stans?
From talking with modev in the comments on their other posts, I suspect we will never know their true goals
At one point they invited me to join their cafe (?) so maybe the goal is just "networking"
It's not documentation, though. That's my point. It's a byproduct of the development cycle, not a place to store important information.
Commit messages are tied to a commit, sure, but why do you expect developers to have better discipline in writing commit messages than they have in updating code comments?