Feature/ add a tag(--body-length-limit) for command commit by yjaw · Pull Request #1849 · commitizen-tools/commitizen

yjaw · 2026-02-05T00:16:11Z

Description

I added a tag (—body-length-limit) for command commit. This tag utilizes Python’s built-in library, textwrap, to rewrap the body. It also respects the user’s |(\n) signal. This tag will affect the footer as well.
The flow is as follows:

Split the body into separate lines using the \n character.
Start from the third line, where the body begins. Use textwrap to rewrap that line.
Reconstruct the entire body message from those rewrapped lines.

Checklist

I have read the contributing guidelines

Was generative AI tooling used to co-author this PR?

Yes (please specify the tool below)

Generated-by: [Gemini] following the guidelines

Code Changes

Add test cases to all the changes you introduce
Run uv run poe all locally to ensure this change passes linter check and tests
Manually test the changes:
- Verify the feature/bug fix works as expected in real-world scenarios
- Test edge cases and error conditions
- Ensure backward compatibility is maintained
- Document any manual testing steps performed
Update the documentation for the changes

Documentation Changes

Run uv run poe doc locally to ensure the documentation pages renders correctly
Check and fix any broken links (internal or external)

Expected Behavior

This option should modify the line length for your message if its length exceeds the limit you’ve set.
Adding this tag or setting it to 0 should have no effect.
If the message body is empty, it will be fine.
This option will affect the text in both the body and footer sections.

Steps to Test This Pull Request

When using the commit command, you can add the —body-length-limit [int] option to set a limit on the length of the commit message. If you don’t want to set a limit, you can set the option to 0.

Additional Context

close #1597

…nd commit

codecov · 2026-02-05T00:18:31Z

⚠️ JUnit XML file not found

The CLI was unable to find any JUnit XML files to upload.
For more help, visit our troubleshooting guide.

bearomorphism

Thanks!

bearomorphism · 2026-02-05T12:59:42Z

tests/commands/test_commit_command.py

+    )
+
+    # Execute with body_length_limit
+    commands.Commit(config, {"body_length_limit": 72})()


The number 72 should be extracted.

bearomorphism · 2026-02-05T13:02:55Z

tests/commands/test_commit_command.py

+            assert len(line) <= 72, (
+                f"Line exceeds 72 chars: '{line}' ({len(line)} chars)"
+            )
+


Add a file regression check here and remove assert line[0] == ... and assert line[1] == ...

bearomorphism · 2026-02-05T13:04:41Z

tests/commands/test_commit_command.py

+    commit_mock = mocker.patch(
+        "commitizen.git.commit", return_value=cmd.Command("success", "", b"", b"", 0)
+    )


Please reuse commit_mock fixture. Same for other new tests.

bearomorphism · 2026-02-05T13:06:14Z

tests/commands/test_commit_command.py

+    assert lines[1] == ""
+    body_lines = lines[2:]
+    for line in body_lines:
+        if line.strip():


This if can be removed?

I believe so. This line was intended to skip empty lines, which are no longer necessary.

bearomorphism · 2026-02-05T13:07:44Z

tests/commands/test_commit_command.py

+    # All lines should be <= 45 chars
+    for line in body_lines:
+        if line.strip():
+            assert len(line) == 45, (


Why not <=?

In this test case, every line is exactly 45 characters long, so I check if it truly wraps to 45-character lines. However, there’s a case where it wraps to a line shorter than 45 characters which is not the intended behavior but test still can pass.

I forgot to modify the comment.

That is strange. Wrapping should not guarantee exactly N chars long.

bearomorphism · 2026-02-05T13:14:14Z

tests/commands/test_commit_command.py

+
+
+@pytest.mark.usefixtures("staging_is_clean")
+def test_commit_command_with_body_length_limit_wrapping(


I think all the new tests can be merged into one and use parameterize to shorten the tests

Basically we can do like following:

fixtures parameterize def test_...(...): mocker.patch( "questionary.prompt", return_value={ "prefix": "feat", "subject": "add feature", "scope": "", "is_breaking_change": False, "body": body, # parameterized, can be a long text with / without line breaks or short strings or an empty string "footer": "", }, ) # commit with parameterized config # check each line in line[2:] does not exceed the line length limit if it is not 0 # file regression check

I understand! This will make the test more organized.

bearomorphism · 2026-02-05T13:15:01Z

commitizen/commands/commit.py

+        if (
+            body_length_limit is None or body_length_limit <= 0
+        ):  # do nothing for no limit


Suggested change

if (

body_length_limit is None or body_length_limit <= 0

): # do nothing for no limit

if (

body_length_limit <= 0

): # do nothing for no limit

Quick question: I understand that the value is guaranteed, but according to defensive programming, isn’t it better to handle the null value?

I am not sure whether body_length_limit is guaranteed to be an int. If it is None under some code paths, then something might be wrong.

commitizen/commands/commit.py

bearomorphism · 2026-02-05T13:21:31Z

commitizen/commands/commit.py

+        # First line is subject, second is blank line, rest is body
+        subject = message_parts[0]
+        blank_line = message_parts[1]
+        body = message_parts[2].strip()
+        body_lines = body.split("\n")
+        wrapped_body_lines = []
+        for line in body_lines:
+            wrapped_body_lines.append(textwrap.fill(line, width=body_length_limit))
+        wrapped_body = "\n".join(wrapped_body_lines)
+        return f"{subject}\n{blank_line}\n{wrapped_body}"


Suggested change

# First line is subject, second is blank line, rest is body

subject = message_parts[0]

blank_line = message_parts[1]

body = message_parts[2].strip()

body_lines = body.split("\n")

wrapped_body_lines = []

for line in body_lines:

wrapped_body_lines.append(textwrap.fill(line, width=body_length_limit))

wrapped_body = "\n".join(wrapped_body_lines)

return f"{subject}\n{blank_line}\n{wrapped_body}"

# First line is subject, second is blank line, rest is body

wrapped_body_lines = [textwrap.fill(line, width=body_length_limit) for line in lines[2:]]

return "\n".join(chain(lines[:2], wrapped_body_lines))

Wow, this code is so clean! I Learned a lot.

Co-authored-by: Tim Hsiung <bear890707@gmail.com>

bearomorphism · 2026-02-06T01:40:20Z

commitizen/commands/commit.py

+        if (
+            body_length_limit is None or body_length_limit <= 0
+        ):  # do nothing for no limit


I am not sure whether body_length_limit is guaranteed to be an int. If it is None under some code paths, then something might be wrong.

bearomorphism · 2026-02-06T01:44:05Z

commitizen/commands/commit.py

+        body_lines = body.split("\n")
+        wrapped_body_lines = []
+        for line in body_lines:
+            wrapped_body_lines.append(textwrap.fill(line, width=body_length_limit))


we should use wrap instead of fill

Reference: https://docs.python.org/3/library/textwrap.html#textwrap.wrap

bearomorphism · 2026-02-06T01:45:05Z

tests/commands/test_commit_command.py

+    # All lines should be <= 45 chars
+    for line in body_lines:
+        if line.strip():
+            assert len(line) == 45, (


That is strange. Wrapping should not guarantee exactly N chars long.

bearomorphism · 2026-02-06T01:46:00Z

commitizen/commands/commit.py

                f"Length of commit message exceeds limit ({len(subject)}/{message_length_limit}), subject: '{subject}'"
            )

+    def _rewrap_body(self, message: str) -> str:


why _rewrap? I think _wrap_body is better

yjaw added 2 commits February 4, 2026 16:20

feat(commit): add a tag(--body-length-limit) and a function for comma…

aa15fda

…nd commit

test(commit): add some test for commit --body-length-limit flag

1f74bb2

yjaw requested review from Lee-W, noirbizarre and woile as code owners February 5, 2026 00:16

github-actions bot added pr-status: wait-for-review type: feature A new enhacement proposal labels Feb 5, 2026

bearomorphism reviewed Feb 5, 2026

View reviewed changes

bearomorphism added pr-status: wait-for-modification and removed pr-status: wait-for-review labels Feb 5, 2026

Apply suggestion from @bearomorphism

49bb71b

Co-authored-by: Tim Hsiung <bear890707@gmail.com>

github-actions bot added the pr-status: wait-for-review label Feb 5, 2026

bearomorphism reviewed Feb 6, 2026

View reviewed changes

bearomorphism removed the pr-status: wait-for-review label Feb 6, 2026



		@pytest.mark.usefixtures("staging_is_clean")
		def test_commit_command_with_body_length_limit_wrapping(

Uh oh!

Conversation

yjaw commented Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Checklist

Was generative AI tooling used to co-author this PR?

Code Changes

Documentation Changes

Expected Behavior

Steps to Test This Pull Request

Additional Context

Uh oh!

codecov bot commented Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

⚠️ JUnit XML file not found

Uh oh!

bearomorphism left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

yjaw commented Feb 5, 2026 •

edited

Loading

codecov bot commented Feb 5, 2026 •

edited

Loading