Decide on Git formatting

[RandomSpaceship]

Having the Git messages in a (mostly) standard format makes it significantly easier to see what's changed at a glance.

[RandomSpaceship]

Thoughts:

Format: package or package(node), preferring, in order:

• package(node): sensors(m2m2_lidar)
• language(specification): nix(flake)
• docs(section): docs(architecture)
• chore

Each commit should be a small logical block, which always leaves the code in a working state.

[DingoOz]

+1 for calling this "gitiquette" or "commitiquette" :)

[DingoOz]

Point of style, should the comments after the colon start with a capital letter or lower case?

[RandomSpaceship]

I don't really mind either way, but it probably should be uppercase if we're formalizing it.

[RandomSpaceship]

Relevant projects:
https://www.conventionalcommits.org/en/v1.0.0/
https://conventional-branch.github.io/

I'm personally completely in favour of using Conventional Branch, since I just don't see any downsides. However, I'm a bit more hesitant about Conventional Commits, since it would require dropping the package information in the commit messages to maintain a reasonable message length. On the other hand, I'm no longer sure that including the package name in the commit has much value, since inspecting the commit itself makes it abundantly clear which package is affected, and in addition, some commits simply won't fit cleanly into that schema.

Thoughts?
@DingoOz @UltraFishy

[DingoOz]

I like conventional branch. Although I feel like there is room between bugfix and feature for just "improvements"... but feature can usually cover that and it is better to align with a standard.

As for conventional commits. I am not aware of the short term benefit to the team for the extra work... whilst we are building out the functuonality for v1.0, we won't really have a need for "release notes" as we don't have releases yet and I think conventional commit message's strength is for release notes etc.

Just my thoughts.

[RandomSpaceship]

Regarding your first point - agreed entirely. My view on conventional commits is that it makes it easy to determine the scope of a commit, but like I said, I have mixed feelings on it. Overall I'm personally more in favour of it than against though.

[UltraFishy]

I'm all for the conventional branches! They will convey way more meaning into what's happening with the repo!

I'm not really sure about the conventional commits. I will say that we do need something along the lines of them but I don't know if this standard is the way to go.

[RandomSpaceship]

Fair. What information do you think should be in the message/do you have any preliminary formatting ideas? The format I initially wrote up would be my preference if we decide against CC, but what are your thoughts on that?

[UltraFishy]

Ok what about something like this:

<commit title>

<commit type>: <key change>

Then the commit types could be along the lines of:

• feat
• fix

This would be along the same lines as the conventional commits but alot more light weight. Just like Nigel is saying, we'll need to find a way to do it so that it's not too much of a hassle to implement.

I haven't seen your version, so you might have something on the same lines, but here is my thoughts.

[RandomSpaceship]

I was referring to the second message I posted here, you can see that style in the commits around here.

At first glance I like your suggestion, but there are a couple of things I can see being potential problems:

• What about commits with no description? Should they be prefixed with a type?
• Most of the time the title will be the change(s) made, rendering the description unnecessary
• It could get messy with notes in the extended commit message

If we decided to go with that format, I think it would make more sense to put the type in the commit title, in which case we're back to stripped-down conventional commits.