• 2 Posts
  • 45 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
    9 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.






  • we should just write the code how it should be

    Notably, that’s not what he says. He didn’t say in general. He said “for once, [after this already long discussion], let’s push back here”. (Literally “this time we push back”)

    who need a secure OS (all of them) will opt to not use Linux if it doesn’t plug these holes

    I’m not so sure about that. He’s making a fair assessment. These are very intricate attack vectors. Security assessment is risk assessment either way. Whether you’re weighing a significant performance loss against low risk potentially high impact attack vectors or assess the risk directly doesn’t make that much of a difference.

    These are so intricate and unlikely to occur, with other firmware patches in line, or alternative hardware, that there’s alternative options and acceptable risk.



  • I wasn’t aware the GitHub terms of service explicitly grant / require you to grant permission to fork [within GitHub].

    GitHub ToS section License Grant to Other Users

    By setting your repositories to be viewed publicly, you agree to allow others to view and “fork” your repositories (this means that others may make their own copies of Content from your repositories in repositories they control).

    If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to use, display, and perform Your Content through the GitHub Service and to reproduce Your Content solely on GitHub as permitted through GitHub’s functionality (for example, through forking). […] If you are uploading Content you did not create or own, you are responsible for ensuring that the Content you upload is licensed under terms that grant these permissions to other GitHub Users.









  • They wrote they’re using . as placeholder commit messages.

    I use f for such [f]ollowup/[f]ixup commits, and a for [a]dditional code/components/changesets. Both keys are trivial to enter. When cleaning it up after, f commits are typically squashed into previous ones, and a commits get a description and/or serve as a base for squashing.

    I can see . working well as well, but having a more obvious character (with vertical height/substance) seems preferable.