-
Notifications
You must be signed in to change notification settings - Fork 13
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
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.
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.
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
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
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
Create foo.txt and update bar.txt and buzz.txt
This can be long - leave out combining for now
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?
Describe the files but don't use a count initially.
-
Create .js files
orfile
-
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)
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.