BatmanAoD

Yep, learned it recently from a list of things that are, surprisingly, named after real people. Deb and Ian eventually got married but are now divorced.

It's so out of date that Deb and Ian are no longer together

(...this is actually true, not just a joke)

But "drop-in replacement"? That's a strong and specific claim.

I do actually think that WebAssembly will enable something - maybe Rust, but more likely something simpler - to eventually dethrone JS in the browser. I also do think it seems beneficial to have your client and backend in the same language.

... the issue I have is people lying and saying Rust is a drop in replacement for js

I am genuinely curious whether you've actually seen this claim before, or if you badly misunderstood or are simply exaggerating a claim about Rust being a good language for web servers, or if you simply made this up as a straw-man. I can't imagine anyone who knows what they're talking about using those words I that order.

To be clear, you're saying you trust git metadata to be preserved even when forge/issue-tracking/etc metadata is not?

I suppose that's probably the case more often than not. I think it's still preferable to trust the forge you use than to spend any significant amount of time or effort trying to ensure that the team has strong enough commit-message discipline to compensate for the risk of losing data in an issue-tracker or forge.

"trust them" meaning trust github and gitlab?

My point is that "the comments aren't accurate" is also a people problem. And I absolutely disagree that commit messages are "documentation" of anything except the development history.

They are hard to discover… and hard to use.

Flippin' fantastic, that's exactly what I want out of my documentation tooling.

I absolutely agree it would be better if forge data were part of the repo itself rather than separate. But for teams that are using a forge in the standard way, they should rely on the forge for this sort of thing, rather than hide important information in an obscure git feature.

But how does the alternative solutions compare with regards to maintainability?

Which alternative solutions are you thinking of, and have you tried them?

Rust has been mentioned several times in the thread already, but Go also prohibits "standard" OOP in the sense that structs don't have inheritance. So have you used either Rust or Go on a large project?

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?

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.

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.