michaelcurrin / auto-commit-msg Goto Github PK

Relates to #38

See PNG and SVG files

I've already setup a flow for using the compiled JS files outside of VS Code.

Test and document this, maybe more work is needed to build that and release it.

It could be used as a hook - not in VS Code otherwise it works badly because of VS Code limitations.

It can be available as a globally available NPM package or shell script that calls it. As an alternative to git commit maybe. Maybe as a bin or alias target.

To pre-fill the git message and wait for confirmation (force editing).

e.g.

$ git commit -m $(auto-commit-msg) --edit

It's annoying if the extension is launched not in a dir

Then using open opens a normal window without the extension (or using the global one).

See semantic commit handling of test-temp even if not for integration tests but manual testing

This is a long term goal as the app has simple UI. See the notes in test section of the docs.

Note that there are different approaches to integration tests. The approach in semantic commit messages is nice. It uses vscode-test as a package in dev deps, which is downloaded when added to .vscode-test dir at the root.

I got error messages before that vscode tests would not run while vscode is running, but this seems okay now in vscode-git-semantic-commit when running my fork and vscode 1.48 downloaded.

Here is the approach in git-prefix to downloading and running vscode

		"postinstall": "node ./node_modules/vscode/bin/install",
		"test": "npm run compile && node ./node_modules/vscode/bin/test"

But the tests doesn't actually do much because of limited coverage.

e.g. if the diff is all adding new lines, then "add to foo.txt" vs "update foo.txt" for modify. Or "remove lines from foo.txt" for delete.

e.g. R100 is rename
R96 is modify and rename

Note this assumes rename and move logic already works (and use one or both in the sentence already)

There is unused code in convCommit module - this can be refactored and more used such as arriving as "4 scripts", "3 configs" or 5 CI files"

Must be done after #38 sets the groundwork.

Depends on #38

How about the prefix before the message should always be feat if you add or update a file?

And if you only move or rename, it is refactor.

If you only delete files, then it is chore.

Then #50 later.

Detect if all changes in a file are whitespace (ignore those using a git diff-index flag) or start with # or //. This may not be practical for multi-line comments.

This may also required using diff.

Published to marketplace!

Use just dir for rename

Use move or rename word appropriately

Update tests

Relates to #38

The message would be

changed 16 files, deleted 2 files etc

Says there is nothing to be updated when there are updates available

I'm using this in a workspace where i don't care about commit messages, it's a static repo, of markdown files.

And while this is useful, i would rather it automatically populate the message onsave that way all i have to do is click one button.

Add badges

Add sample image

The prepareCommitMsg module has missing coverage based on the reports.

The functions are used in the app but in the autofill and cli modules which are not practical to test and don't have tests, so prepareCommitMsg appears unused.

But the functions in prepareCommitMsg that are missing tests should still be tested directly.

CONTRIBUTING
.md
.rst

Ruby doc format?

And

CONTRIBUTORS(.*)
CHANGELOG(.*)

See max errors flag. Defaults to minus.

https://eslint.org/docs/user-guide/command-line-interface

Update cookbook. There is also an item there which could be useful

Note that fix flag might not fix everything when run locally but checking for errors without fix flag maybe can give error output

e.g. _lookupStatusAction and status

These don't add value and affect test coverage.

But are worth keeping as a reference for future git status behavior if ever needed

Thanks for this extension, I find it very useful. One problem is that I need to work with some files with spaces in their filenames (nothing I can do about it), and the extension splits the file name at the first blank space. Is there a way to let it handle filenames with any Unicode characters like spaces (and other characters, like Russian letters)?

e.g. Create foo, update bar and delete bazz

Use style in Semantic section - check if the changes are all whitespace only.

For staged, check if there is a diff. and check if the no-whitespace diff is empty (need to check by hand). Then you know there are only whitespace changes.

Repeat for unstaged as fallback.

Otherwise you need to do regex checks against each file diff (maybe using plain diff and not diff-index? either way need patch output)

Flags for diff-index https://www.git-scm.com/docs/git-diff-index

-b
--ignore-space-change

    Ignore changes in amount of whitespace. This ignores whitespace at line end, and considers all other sequences of one or more whitespace characters to be equivalent.
-w
--ignore-all-space

    Ignore whitespace when comparing lines. This ignores differences even if one line has whitespace where the other line has none.

e.g.

update cli.ts and cli.ts

To

update cli.ts and git/cli.ts

Using common root src without using src in either.

First make feat the default

Then if the message is identical, replace feat with fix. And back again?

I might be missing the behavior anyway to detect repeat message which is meant to do nothing, besides this new feature.

Perhaps a way in this extension to get close to the easy GH autofill flow.

To listen for when files are staged on unstaged and then push a message to the input box for you.

VS Code does not work with git hooks. So after getting the shell version working I can look at making a vs code extension based on this one

https://github.com/benjaminadk/emojigit

I could even use my existing command as using the confirmation flow there is a terminal git commit command, but one gets there after using the extension UI. Also the confirmation in the terminal can be toggled. Maybe it is just behind the scenes

If package.json and package-lock.json both change (or only the latter changed) and nothing else, then message can be:

build: Update dependencies

Same for pairs as yarn.lock, Gemfile.lock and maybe Pipfile.lock

See recipes

https://github.com/MichaelCurrin/code-cookbook/tree/master/recipes/ci-cd/github-actions/workflows/build-release-assets

Can there be a way to define a custom prefix before each message? For example

ThisIsARequest - update 4 files delete 1 file

e.g. when working on package files.

chore(deps): - not yet supported
build(deps): - supported

This style is harder and depends on the knowing the codebase.

feat(lang): add polish language

Maybe it can be automated using the highest module for the file or files. e.g. src or lib (for src/lib). The directory could be nested a few levels deep. But also there is some risk of duplication of dir names across dirs.

It's not worth putting a filename.

Well maybe chore(docs) is a good way to mix docs directory with others.

https://www.conventionalcommits.org/en/v1.0.0/

A scope may be provided to a commit’s type, to provide additional contextual information and is contained within parenthesis, e.g., feat(parser): add ability to parse arrays.

A scope MAY be provided after a type. A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., fix(parser):

There is currently a not implemented message setup to be raised on multiple repos in a workspace, but this did not actually trigger.

So either do that, or get the functionality to work in multiple repos (using the scope of the current scope files and message box (there are multiple).

TODO

This has become confusing where testing also runs linting with pretest, but then you're locked
into a linting choice of fix or not. Same for fmt, if it even goes here.
Also should then fmt go in all?

And CI/CD

Relates to #38

e.g.

update 38 .svg files

OR

update 38 SVG files

Perhaps assume feat if no other context can be found.

Then click the button again. If the output message is the same as the input message, then replace feat with fix

Such that clicking the button twice gives "fix".

Perhaps an option can be added in the command prompt to go straight to fix as well.
An extra button would not work so well on a small screen where there are a few other extensions already

And adding a pop-up on the single button would not be a nice flow because mostly its not needed

When docs: etc. is not manually entered already or deducible...

Maybe one chooses from a droplist like the semantic commit message extension and then that is pushed to the commit message.

Currently moving 3 files shows as "rename"

Perhaps a command prompt option or a button. Or just a space in the message bar.

Fill the message bar with chore: etc. but don't fill in the message - this allows for custom messages.

e.g.

• update 3 files in foo
• update 16 files and delete 2 files

Relates to #13

See if enum can be cleaned up

Reverse keys and values?

Change lookup with function or alternate use that is safer than any.

What is proper way to handle undefined, maybe just with if an error?

Check for this error in "Log (Window)"

When there are zero commits

: Error: Command failed: git diff-index --name-status --find-renames --find-copies --no-color --cached HEAD
fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.

https://github.com/MichaelCurrin/auto-commit-msg/releases/download/v0.7.0/auto-commit-msg-0.7.0.vsix

Something like

https://github.com/MichaelCurrin/auto-commit-msg/releases/download/latest/auto-commit-msg.vsix

Use in the docs with a download button

This is something part of standard git hook for commit message, where a check is done to see if the message comes from a template.

If this is not possible, then just read the actual value of commit.template e.g. _COMMIT_MESSAGE and use that as a prefix.

This is useful as a simple alternative to reading from the branch name (which is covered by the git-prefix extension already). And allows manually entering a ticket message or project name that is not based on branch name.

There is a low priority issue though

Relates to #38

What happens when there is an old message when making a count message? Throw it away? Especially not useful if the old msg is a count and mixing old and new count messages doesn't make sense or look good.

Maybe keep the conv commit portion