Skip to content

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

Description

@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.

Activity

  1. woile commented on May 7, 2024

    @woile
    Member

    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

  2. codevogel commented on May 7, 2024

    @codevogel
    Author

    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.

  3. woile commented on May 7, 2024

    @woile
    Member

    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

  4. Lee-W commented on May 13, 2024

    @Lee-W
    Member

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

  5. locked and limited conversation to collaborators on May 13, 2024
  6. converted this issue into a discussion #1104 on May 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions