-
-
Notifications
You must be signed in to change notification settings - Fork 301
-
Description
I like using the scope descriptor to see which files a commit is altering
If I commit a single file, it would be nice to have the option to auto-fill the 'scope' dialogue with the name of that file, relative to the root directory.
e.g. if I were to do this:
// in root dir on a clean worktree
$ touch some_dir/some.file
$ git add .
$ cz c
I would expect the cz c dialogue to pop-up, where I can choose fix/feat etc., then when I am asked 'What is the scope of this change?' I would expect the text input to be prefilled with some.file, so I can change it to something else, or just hit enter to continue.
This would not be applicable if a commit contains multiple files, as a file-based scope doesn't make sense there, so I would expect the scope field to be left blank in that case.
Possible Solution
Add a boolean option prefill_scope_for_single_files that defualts to false and when set to true, makes the CLI tool scan for the number of files that have changed upon asking the scope question.
If the number of files is one, grab the filename and pre-fill it as the scope.
Optional: add boolean opt prefill_scope_for_single_files_relative that defaults to false and determines whether the scope should be prefilled with some.file (when opt is false) or some_dir/some.file (when opt is true)
Additional context
This would have to be an opt-in feature for sure as some people skip the scope step.
Beta Was this translation helpful? Give feedback.
All reactions
Replies: 4 comments
-
The recommendation is to build your own cz rules that does this file detection
https://commitizen-tools.github.io/commitizen/customization/#2-customize-through-customizing-a-class
Beta Was this translation helpful? Give feedback.
All reactions
-
The recommendation is to build your own cz rules that does this file detection
https://commitizen-tools.github.io/commitizen/customization/#2-customize-through-customizing-a-class
Excuse me if I'm misunderstanding, but I'm not sure how I could hook into prefilling the input buffer using a custom ruleset. I see that is is possible to add your own questions, and apply some filtering logic on the responses, but I don't see a clear way of A) inheriting an existing ruleset and B) pre-filling content in the buffer. If there is a way, could you point me in the right direction?
I could see a way to solve problem A by keeping a manually adjusted version of said ruleset, but this would not be very flexible with other rulesets, or if (although unlikely) changes were made to the default rulesets that ship with commitizen.
Beta Was this translation helpful? Give feedback.
All reactions
-
Something like (didn't test it):
from warnings import warn from commitizen.cz.conventional_commits import ConventionalCommitsCz from commitizen.defaults import Questions from commitizen import cmd class MyCustomCZ(ConventionalCommitsCz): def get_path(self) -> str: # this c = cmd.run(f"git diff --diff-filter=d --name-only") # or something more advanced, compare against against the last tag # c = cmd.run(f"git diff --diff-filter=d --name-only $(git tag --sort=creatordate --merged | tail -n 2 | head -n 1)") if c.return_code == 0: raise SystemExit(c.err) return c.out def questions(self) -> Questions: scope_default = self.get_path() questions = super().questions() try: questions[1]["scope"]["default"] = scope_default except (IndexError, ValueError) as e: warn("Commitizen broke compatibility which should not happen. Please report this issue.") raise e return questions
To prevent the warn you can pin to a specific version of commitizen in your requirements.txt and let renovate send you updates for new versions and merge automatically if the tests pass
Beta Was this translation helpful? Give feedback.
All reactions
-
Instead of an issue, it's more like a discussion. Let me move it to discussion
Beta Was this translation helpful? Give feedback.