I've been working on #96 lately and have been struggling to remember the de facto git commit message format for tests. It occurs to me that this is a solveable problem.
If committing a new source file, format the commit message following these
guidelines:
$ git commit -m 'tool(1): add feature x'
If committing a new library or header file:
$ git commit -m 'library(3): fix overflow'
$ git commit -m 'header.h(3): add header.h(3)'
If committing a new manual page:
$ git commit -m 'tool.1: add author details'
If modifying some other file or directory:
$ git commit -m 'README: clarify'
$ git commit -m 'tests/posix: fix bug #47'
For multiple of these:
$ git commit -m 'Makefile, tool(1): add tool(1)'
$ git commit -m 'tool(1): add tool(1); library(3), library.3: add library(3)'
$ git commit -m 'tool(1): fix #42 & add feature x'
Commit messages should be written in the present tense.
These are good, unambiguous (as far as I can see; when they aren't, contributors can file an issue) rules that don't get in the way, make contributing easier (by taking the guesswork out of writing commit messages and making the log easier to read), and for which there need to be few exceptions. In fact, this lack of friction is one of the reasons I love working on Bonsai - I can really just focus on writing code, and not paperwork.
A current issue I have, though, is remembering how to format commit messages deeper in the tree - tests/bonsai/dj.mk in #96, for instance. I don't believe the format is codified yet - or at least not explicitly - but even if it was, I would probably still struggle to remember it, and spend time consulting docs, which isn't as rewarding for me.
I'd like to implement a simple make commit recipe in the top-level Makefile. This would drop the incanter into $VISUAL with part of the commit message already written - the boring part; the file changed. Adding files to a commit would be unchanged - the usual git add. Writing the file prefix of the commit would be a few lines of shell. And for special commits that don't need a file prefix, the committer can just ^H a couple times. This could also make moving to another VCS easier on our muscle memories (which will probably never happen, but you never know).
I've been working on #96 lately and have been struggling to remember the de facto git commit message format for tests. It occurs to me that this is a solveable problem.
[`CONTRIBUTING`](https://git.tebibyte.media/bonsai/harakit/src/branch/main/CONTRIBUTING) says:
```
If committing a new source file, format the commit message following these
guidelines:
$ git commit -m 'tool(1): add feature x'
If committing a new library or header file:
$ git commit -m 'library(3): fix overflow'
$ git commit -m 'header.h(3): add header.h(3)'
If committing a new manual page:
$ git commit -m 'tool.1: add author details'
If modifying some other file or directory:
$ git commit -m 'README: clarify'
$ git commit -m 'tests/posix: fix bug #47'
For multiple of these:
$ git commit -m 'Makefile, tool(1): add tool(1)'
$ git commit -m 'tool(1): add tool(1); library(3), library.3: add library(3)'
$ git commit -m 'tool(1): fix #42 & add feature x'
Commit messages should be written in the present tense.
```
These are good, unambiguous (as far as I can see; when they aren't, contributors can file an issue) rules that don't get in the way, make contributing easier (by taking the guesswork out of writing commit messages *and* making the log easier to read), and for which there need to be few exceptions. In fact, this lack of friction is one of the reasons I love working on Bonsai - I can really just focus on writing code, and not paperwork.
A current issue I have, though, is remembering how to format commit messages deeper in the tree - `tests/bonsai/dj.mk` in #96, for instance. I don't believe the format is codified yet - or at least not explicitly - but even if it was, I would probably still struggle to remember it, and spend time consulting docs, which isn't as rewarding for me.
I'd like to implement a simple `make commit` recipe in the top-level `Makefile`. This would drop the incanter into `$VISUAL` with part of the commit message already written - the boring part; the file changed. Adding files to a commit would be unchanged - the usual `git add`. Writing the file prefix of the commit would be a few lines of shell. And for special commits that don't need a file prefix, the committer can just `^H` a couple times. This could also make moving to another VCS easier on our muscle memories (which will probably never happen, but you never know).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
I've been working on #96 lately and have been struggling to remember the de facto git commit message format for tests. It occurs to me that this is a solveable problem.
CONTRIBUTINGsays:These are good, unambiguous (as far as I can see; when they aren't, contributors can file an issue) rules that don't get in the way, make contributing easier (by taking the guesswork out of writing commit messages and making the log easier to read), and for which there need to be few exceptions. In fact, this lack of friction is one of the reasons I love working on Bonsai - I can really just focus on writing code, and not paperwork.
A current issue I have, though, is remembering how to format commit messages deeper in the tree -
tests/bonsai/dj.mkin #96, for instance. I don't believe the format is codified yet - or at least not explicitly - but even if it was, I would probably still struggle to remember it, and spend time consulting docs, which isn't as rewarding for me.I'd like to implement a simple
make commitrecipe in the top-levelMakefile. This would drop the incanter into$VISUALwith part of the commit message already written - the boring part; the file changed. Adding files to a commit would be unchanged - the usualgit add. Writing the file prefix of the commit would be a few lines of shell. And for special commits that don't need a file prefix, the committer can just^Ha couple times. This could also make moving to another VCS easier on our muscle memories (which will probably never happen, but you never know).There is a lot more of an idiomatic way to do this with git hooks. Do you want me to implement that instead?
That sounds neat, please do!
I’ve got a working version of this, by the way. Just need to polish it up and it’ll be ready for a PR.