Personally (without conventional commits) I tend to put them at the end in parentheses if the commit has something to do with that issue. But if there is a stronger relationship like that it fixes the issue, I put a `Fixes` trailer in the message as well.

I can not say anything nice about conventional commits. The format takes up space in the most-read part of the message. The categories or types have little information. They can be replaced with an honest English verb embedded in the subject like a sentence. It also reads way better with just a sentence instead of three kinds of punctuation (:, (), !). Okay, I can tolerate an "area" in the subject. And that predates this conventio.

At my dayjob we make a webapp for non technical people. I can write a changelog for that just fine (in norwegian). The commit messages are irrelevant to the users. And demanding that all commits should be good enough for an end-user changelog? That's not happening for us anytime soon.

Use footers/trailers instead.

Someone skilled enough should have many original enough problems to work on. But such persons would have to speak on that topic.

   What accessibility settings do you need?

   - [four options/catgories]
   - Remind me Later (or something)

Some years ago I realized that I can just start sending emails to an OSS mailing list. Without introduction just starting to post as if I belonged there. I had already made some grammar fixes more than five years before that but I started to comment and critique submissions. And submitting my own patches. Now checking the mailing list is daily habit. Unfortunately I didn't have time to post the second version of a submission on the bus today (another documentation fix).

People, and especially in my culture, are very good at staying out of places where they do not belong through self-policing alone. Unfortunately to the point where at least I do get stuck in narrow patterns and never even consider certain opportunities.

https://docs.oracle.com/javase/8/docs/technotes/guides/langu...

And I'm pretty happy with its design considering its age.

Notably this is not a function call and indeed things are not called unless you enable it. Contrast with Zig. So I guess you will only suffer from code bloat if you never enable them.

The tutorial mentions the dangers of side effects. But it also mentions how to use them for more complicated assertions. That's natural since you'll want something like that when you need to check a post-condition.

Programming assertions get joked on because of, ahem.

- Step one: Turn on extra checks in test environments where the stakes are low

- Step two: Turn them off in production (with realistic data because prod eq. reality) to save cycles

And that seems to be partially accurate. However the truly interesting assertions can test complex conditions that might break complexity (Big O) contracts. Like a private mininum function that is advertised as O(1) on account of taking a sorted list. But there is no type guarantee that the list is sorted. So you assert that it is sorted. But that breaks the complexity contract.

Overall I have not used assertions in Java for trivial conditions in like five years. They're better deployd for something more complex than that.

Then there is the whole thing about -- and more topics to be sure -- crashing the whole application or not. That's not necessarily great for us regular Java programmers. However we can (though discoraged) catch AssertionError if we want to.

Java did the right thing for assertions but then completely failed for the analoguous issue when it comes to logging.

I admit that logging is more complex because you often want it configurable dynamically at runtime. But I'd argue that the language should not be in your way if all you need is a compile time decision and the contortions we made for logging to stay low cost when nothing is logged are crazy in Java.

No one wants to apply diffs in commit messages. But some people use this technique via email:

    Finally fix it

    ---

    Changes in v2:

    - Proper formatting
    - Remove irrelevant typo fix

I would personally use Git notes instead though.

    Finally fix it

    ---

    Notes:
        Changes in v2: ...

This means that it will try to apply any unindented diffs in the commit message. But you’re fine if you indent the diff. (Newschool code fencers will have a worse time here.)

I imagine that this worked fine for changes that were authored by one person and submitted by another person via email, or by their friend, or by someone trying to resurrect a previous attempt at getting something upstreamed. Someone is likely to notice that examples diffs are getting applied. But it won’t work well at all if you are some software distributor who is using patch files to apply modifications to packages.

Recall that git-am(1) will not apply indented diffs. Well have a look at my GNU patch 2.7.6:

    If the entire diff is indented by a consistent amount, if lines end in
    CRLF, or if a diff is encapsulated one or more times by prepending "- "
    to lines starting with "-" as specified by Internet RFC 934, this is
    taken into account.

    Larry Wall wrote the original version of patch.