Option to auto-fill the filename as the scope when commiting single file using the CLI

[codevogel]

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.

[woile]

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

[codevogel]

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.

[woile]

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

[Lee-W]

Instead of an issue, it's more like a discussion. Let me move it to discussion