Description
I strongly believe in semantic correctness.
git commits are supposed to be single purposed, useful, and have a descriptive and relevant message associated with it.
The current lack of ability to configure the plugin to prompt for the message is leaving me to make my commits outside the editor, in the CLI.
As it stands, this is no better than an fs backup with rollback capabilities.
For context below, there isn't an "official" standard set by anyone that's concrete, but the rather universally accepted standard is the following:
- A subject line that is less than 80 chars that gives a quick insight to the purpose and contents of the commit, while being identifiable from the other commit messages.
- An empty second line, when there is the following section:
- Following the empty second line, when necessary, a section of text giving further details into the purpose and contents of the commit, as well as other useful commentary, the number of lines being arbitrary in length, each line being 80 chars or less.
As for prompting the user, there are two ways most git programs allow users to enter a commit message, they consist of:
- Providing a simple multi-line text input field and leave it to the user to format their entry to be compliant, or ignore compliance should they wish.
- Providing a single-line text input field labeled "Subject", and following it, a multi-line text text input field labeled "Description".
- The utility then joins the two string together with two newlines, resulting in the second line being empty and compliant.
- Some utilities warn the user in some fashion if any line lengths grow to be non-compliant.
I personally like the latter, and I am unopinionated if warnings/notices should be implemented for line length being exceeded.
As much as I despise typescript, I might look at making a PR. cough probably after making a flake first lmao cough