-
Notifications
You must be signed in to change notification settings - Fork 14
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.
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.
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.
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
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, 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.
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.
Single common action.
ACTION X files
create 5 files
rename 10 files
delete 4 files
move 2 files
update 6 files
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
andsrc/foo/xyz.txt
both being insrc
. But does not add value files are insrc
anddocs
for example and the common value isroot
.
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
create X files and delete Y files
create X files and rename Y files
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.
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
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
feat
fix
chore
test
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.