Repository navigation
Can't bump without using annotated_tag #879
Description
Description
Description and code analysis
When running cz bump with commitizen 3.10.0 and git 2.34.1, a commit is performed, but the command hangs out indefinitely when trying to tag.
I debug the code, and it hangs in: commitizen/git.py when running cmd.run, because without settings annotated or lightweight tag, the command it tries to launch (without the _opt parameter then), results in git tag 0.2.0, which if you'd run it in a terminal, would open an editor to add a message.
This does not happen when specify lightweight or annotated message because then the message is added:
def tag(tag: str, annotated: bool = False, signed: bool = False) -> cmd.Command:
_opt = ""
if annotated:
_opt = f"-a {tag} -m"
if signed:
_opt = f"-s {tag} -m"
c = cmd.run(f"git tag {_opt} {tag}")
return c
Without those options, in commitizen/cmd.py, the stderr value returned by process.communicate hangs out, and the stacktrace produce by a SIGTERM specify:
b"Vim: Warning: Output is not to a terminal\nVim: Warning: Input is not from a terminal\n\r\nerror: There was a problem with the editor '/usr/bin/vim'.\nPlease supply the message using either -m
or -F option.\n"
The same appears with vi, if git is configured with vi (git config --global core.editor /usr/bin/vi).
Draft of solution
I did not dig any further, so maybe I'll be irrelevant here, but would it be relevant to always specify a commit message, or maybe add a -m ""
Great tool anyway!
Steps to reproduce
- Run cz bump, without lightweight or annotated tag setup enabled
Current behavior
When running cz bump with commitizen 3.10.0 and git 2.34.1, a commit is performed, but the command hangs out indefinitely when trying to tag.
So the command fails, and the state becomes inconsistent, because of a bump commit in git, without a tag associated with it.
Desired behavior
The tag is performed successfully during the bump.
Screenshots
No response
Environment
Commitizen Version: 3.10.0
Python Version: 3.9.7 (default, Mar 21 2023, 20:41:25)
[GCC 11.3.0]
Operating System: Linux
Git 2.34.1
Activity
Lee-W commentedon May 20, 2024
Hi @CharlesAracil , sorry for the late reply. I just tested it without encountering the issue. I also noticed the code you mentioned hasn't been touched. I suspect his might be due to some git setting. Do you change tag-related git settings? I also have my git editor set up this way but does not have editor opened when running
git tag 0.2.0.akiross commentedon Dec 13, 2024
Hello, I'm experiencing a similar issue with commitizen 3.29.0: it seems it was due to a tag-related setting as you suggested:
It's unclear to me why this signing setting will lead to prompting for a message. Still, I would consider explicitly passing
-mto git as suggested by OP.bassemkaroui commentedon Apr 10, 2025
Indeed I have the same issue because I configured git to sign any tag automatically.
cz bump -sfixed the problem.syhe commentedon Mar 18, 2026
FYI: The reason
gpgsign = true(or-son the commandline) causesgitto prompt for a message is that signatures can only be attached to annotated tags.https://git-scm.com/book/en/v2/Git-Basics-Tagging
A way to avoid
czhanging in this case would probably be to setGIT_EDITORto something that does nothing, like ":" (a shell built-in).bearomorphism commentedon May 9, 2026
Triage from #1964: Looks fixed on master (4.15.1).
commitizen/git.py(lines 170-177) now generates a lightweight tag viagit tag <tag>with no-m(and so no editor prompt). This avoids theVim: Warning: Output is not to a terminal...hang. Closing recommended unless someone can still reproduce on 4.15.1.bearomorphism commentedon May 9, 2026
Verification update (re #1964)
I reproduced this against current master (4.15.1) on Windows with
core.editor=vim:.cz.tomlhaving noannotated_tag/ nogpg_sign.cz bump --yes.v0.2.0created (objecttype=commit).Verdict: FIXED — closing-eligible.
bearomorphism commentedon May 9, 2026
Feel free to reopen is this issue still persists, thanks!