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 my Project board https://github.com/users/MichaelCurrin/projects/4

One file

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.

One file multiple actions

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 and update bar.txt and buzz.txt

This can be long - leave out combining for now

Many files

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

Single common action.

ACTION X files

• Create 5 files
• Create 5 files in DIR
• Create 5 files in DIR and DIR
• Rename 10 files
• Rename 10 files in DIR

---

Modified files or mixed updates (create/remove/rename)

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

---

Mixing multiple actions on one or multiple lines is hard - is it the same files in Create X files and rename Y files ? What is overlap in X and Y?

Type or content

Describe the files but don't use a count initially.

• Create .js files or file
• 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)

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.