Message output samples

Sample output for what the tool will produce when it is finished and working. All of these cases should be covered in unit tests eventually. The order here is for incremental development such that the easy ones can be done first and the tool has some use before other cases are handled.

See Features doc with a list of issues.

For my own reference - see the Project board, created before this repo existed.

One file ✅

This is done.

Ignore the directory. Just use the verb and a filename. This is the priority for getting a working version of this project. If the change is more than one file, then use empty message.

ACTION FILENAME

• Create foo.txt
• Modify foo.txt
• Delete.txt
• Rename foo.txt
• Move foo.txt to bar/foo.txt

Note that "Initial commit" is not that useful by itself, but maybe combined with a create message. Also this is not frequent so can be left for later.

Semantic commits on one file

Adding to the above, which is most of my commits, add a semantic commit around:

• docs - README.md and docs dir. Later ignore Jekyll markdown files as content)
• chore - configs and package files. Also YAML and JSON in general except when specifying exceptions for this rule as a project. Also rename and delete are chores.

One file multiple actions ✅

This is done.

Combinations are limited. You could do unlike combinations like delete and create same filename when you meant to modify or move. These can be covered later by treating all actions as the same rather than rules for each. Be guided by git st

Common cases

• Update and rename foo.txt
• Update and move fizz/buzz.txt to buzz.txt

One file what changed 🚧

Advanced form of update.

Eventually the content could be detected e.g. detect if only one character was added or whitespace was changed. Or created empty file. But the value is not that great, there aren't so many useful cases, and the effort is high.

Look at what changed:

Add X lines to FILENAME
# OR
Remove X lines in FILENAME
# OR
Update X lines in FILENAME # for add and remove

Change permissions on FILENAME # executable

Change permissions and update FILENAME

Few files

Same action ✅

See One file spec for other actions.

• Update foo.txt and bar.txt
• Delete foo.txt and bar.txt
• Update foo.txt, bar.txt and baz.txt
• Move foo.txt, bar.txt and baz.txt to buzz - only if they move to the same place, otherwise just "move" and no dest.

When it gets to more than 3 it is too long.

• Update foo.txt and fizz/bar.txt
• Update fizz/foo.txt and fizz/bar.txt
• Update foo.txt and bar.txt in fizz

Mixed modified - mix add, remove lines and modified together

• Update foo.txt, bar.txt, fizz/foo.txt

Collapse update and permission

Different action 🚧

• Create foo.txt, update bar.txt and update buzz.txt
• Create foo.txt, update bar.txt and delete buzz.txt

Each path gets a verb. Don't worry about sorting yet, but later this can be sorted on action (create before delete) and then by path.

Many files

The limit of when this is needed can be configured (e.g. > 4 files or message is too long). Or add two modes (buttons) to choose from as buttons to click on.

I need a new module to handle this. Figure out how to focus on data rather than formatting - delay formatting as it is easier to pass around, work with and test data as a separate fields.

Basic ✅

Single common action.

ACTION X files

• create 5 files
• rename 10 files
• delete 4 files
• move 2 files
• update 6 files

Single directory 🚧

Note DIR is add-on and not needed for first pass. But adds more meaning.

• create 5 files in DIR
• rename 10 files in DIR

Regarding finding DIR value:

• Check if all file's parent directory is equal, then don't need to get the common dir for each.
• Otherwise fallback to getting the common directory. This maybe useful for src/abc.txt and src/foo/xyz.txt both being in src. But does not add value files are in src and docs for example and the common value is root.

Multiple directories 🚧

update X files in DIR # highest common path as long as possible e.g. foo/bar
update X files in DIR and DIR #?
update X files in DIR and Y files in DIR

Mixed updates ✅

create X files and delete Y files
create X files and rename Y files

Type of content 🚧

Single file 🚧

This is not so useful for a single file as you can see the name, path and extension.

Also there is overlap with Convention Commit - you see a file in a config or CI file as use that a signal.

No need to say script if something is clearly .py or whatever.

Multiple files 🚧

This works for multiple files - whether few or many.

Describe the files. Ideas:

• Create .js files (no need to get wordy and say Python or TypeScript, also extension generalizes well)
• Create .js and .ts files maybe
• Create scripts (for .py, .js, etc. using known extensions)
• Create configs (for known config files)
• Create package file (this could cover Gemfile, package.json, etc. as a general label instead of naming it)
• Update packages (for package.json + yarn.lock/package-lock.json, or mix of Gemfile and package.json etc. though recently I prefer to list those separately)

This could be extended to have a count. I don't know if this is useful for common enough.

• Create 5 scripts
• Create 2 scripts and 3 configs (if there are two many categories this becomes too long)

What about this - too vague?

• Create 5 scripts and configs

Semantic commits ✅

Note that semantic commit messages are easy to add with a command-line flag or variation of the command, but the IDE would need a new extension to handle this.

The semantic commit messages can be inferred in some cases - using known doc or chore files, but not assuming a feature or fix. Included here for full context but not needed for the first pass. The bigger win is without the prefix for now.

When there are mixed actions in the content, rather than leaving the value out, there can be a precedence.

e.g. If there is a chore and a docs change one commit, using chore.

Think of what value you'd be reporting to business or devs as the most important or highest impact and leaving out the others.

First two are hard to infer

1. feat
2. fix
3. chore
4. test
5. docs

Alternatively, count the files - if there are 2 doc changes and one rename, then use the majority as docs.

Also creating or updating files in docs can all be considered docs, regardless of extension. For example images and markdown files.