• 27 Posts
  • 369 Comments
Joined 1 year ago
cake
Cake day: June 11th, 2023

help-circle





  • Kissaki@programming.devtoGit@programming.devGit Commit Creation
    link
    fedilink
    English
    arrow-up
    3
    ·
    edit-2
    4 days ago

    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.














  • 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.




  • Release must be documented

    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.