opdavies/oliverdavies.uk
1
0
Fork 0
Code Issues 1 Pull requests Projects 1 Releases Packages Wiki Activity Actions

Add daily email

Browse source
This commit is contained in:
Oliver Davies 2025-07-10 00:08:06 +01:00
parent fd8735b9d7
commit 3d76aa0c3b
3 changed files with 132 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

7
content/meta/index.json
View file

@ -6758,5 +6758,12 @@
],
"node.736063cc-b727-46f4-9a12-3b344d919614": [
"user.b8966985-d4b2-42a7-a319-2e94ccfbb849"
],
"node.52d92e80-5970-4525-b4b6-b30562f5573c": [
"user.b8966985-d4b2-42a7-a319-2e94ccfbb849",
"node.c74de3cf-5362-4d08-935a-a9d0d22fcb94"
],
"path_alias.ceccc753-915b-4361-96d3-44bdbc17bca8": [
"node.52d92e80-5970-4525-b4b6-b30562f5573c"
]
}

98
content/node.52d92e80-5970-4525-b4b6-b30562f5573c.json Normal file
View file

@ -0,0 +1,98 @@
{
"uuid": [
{
"value": "52d92e80-5970-4525-b4b6-b30562f5573c"
}
],
"langcode": [
{
"value": "en"
}
],
"type": [
{
"target_id": "daily_email",
"target_type": "node_type",
"target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
}
],
"revision_timestamp": [
{
"value": "2025-07-09T23:07:33+00:00"
}
],
"revision_uid": [
{
"target_type": "user",
"target_uuid": "b8966985-d4b2-42a7-a319-2e94ccfbb849"
}
],
"revision_log": [],
"status": [
{
"value": true
}
],
"uid": [
{
"target_type": "user",
"target_uuid": "b8966985-d4b2-42a7-a319-2e94ccfbb849"
}
],
"title": [
{
"value": "What type of change are you making?"
}
],
"created": [
{
"value": "2025-07-06T23:06:53+00:00"
}
],
"changed": [
{
"value": "2025-07-09T23:07:33+00:00"
}
],
"promote": [
{
"value": false
}
],
"sticky": [
{
"value": false
}
],
"default_langcode": [
{
"value": true
}
],
"revision_translation_affected": [
{
"value": true
}
],
"path": [
{
"alias": "",
"pid": null,
"langcode": "en"
}
],
"body": [
{
"value": "Whilst I don't use the [conventional commits][0] approach to writing commit messages any more, I still think it's important to think about the type of change when a commit is made to a code repository.\r\n\r\nAre you adding a new feature?\r\n\r\nAre you fixing a bug?\r\n\r\nAre you refactoring some code?\r\n\r\nConventional commits has you add keywords like `feat`, `fix`, `chore` and `refactor` to the commit message to identify the type of change being committed.\r\n\r\nI don't add it to the commit message, but I do ask myself the same question.\r\n\r\nWhat type of change is this?\r\n\r\nIf it's more than one, it probably needs to be split into separate commits.\r\n\r\nThis makes the intent clearer and the change easier to review.\r\n\r\nIf you need to refactor some code before adding a feature, they should be two separate commits.\r\n\r\nIf you're fixing a bug, commit a failing test first so it can be easily seen and then commit the fix that makes the test pass.\r\n\r\n## Here's the thing\r\n\r\nHaving one change per commit makes it easier to write good commit messages as the change is simpler to explain.\r\n\r\nIf a commit includes multiple changes, it is more difficult and causes commit messages like `Updates` or `wip` - which I try to avoid, especially on client and open source projects.\r\n\r\n[0]: \/daily\/2022\/09\/01\/conventional-commits-changelogs",
"format": "markdown",
"processed": "<p>Whilst I don't use the <a href=\"http:\/\/localhost:8888\/daily\/2022\/09\/01\/conventional-commits-changelogs\">conventional commits<\/a> approach to writing commit messages any more, I still think it's important to think about the type of change when a commit is made to a code repository.<\/p>\n<p>Are you adding a new feature?<\/p>\n<p>Are you fixing a bug?<\/p>\n<p>Are you refactoring some code?<\/p>\n<p>Conventional commits has you add keywords like <code>feat<\/code>, <code>fix<\/code>, <code>chore<\/code> and <code>refactor<\/code> to the commit message to identify the type of change being committed.<\/p>\n<p>I don't add it to the commit message, but I do ask myself the same question.<\/p>\n<p>What type of change is this?<\/p>\n<p>If it's more than one, it probably needs to be split into separate commits.<\/p>\n<p>This makes the intent clearer and the change easier to review.<\/p>\n<p>If you need to refactor some code before adding a feature, they should be two separate commits.<\/p>\n<p>If you're fixing a bug, commit a failing test first so it can be easily seen and then commit the fix that makes the test pass.<\/p>\n<h2>Here's the thing<\/h2>\n<p>Having one change per commit makes it easier to write good commit messages as the change is simpler to explain.<\/p>\n<p>If a commit includes multiple changes, it is more difficult and causes commit messages like <code>Updates<\/code> or <code>wip<\/code> - which I try to avoid, especially on client and open source projects.<\/p>\n",
"summary": ""
}
],
"field_daily_email_cta": [
{
"target_type": "node",
"target_uuid": "c74de3cf-5362-4d08-935a-a9d0d22fcb94"
}
]
}

27
content/path_alias.ceccc753-915b-4361-96d3-44bdbc17bca8.json Normal file
View file

@ -0,0 +1,27 @@
{
"uuid": [
{
"value": "ceccc753-915b-4361-96d3-44bdbc17bca8"
}
],
"langcode": [
{
"value": "en"
}
],
"path": [
{
"value": "\/node\/52d92e80-5970-4525-b4b6-b30562f5573c"
}
],
"alias": [
{
"value": "\/daily\/2025\/07\/06\/what-type-change-are-you-making"
}
],
"status": [
{
"value": true
}
]
}