Repository navigation
Configuration flag to prevent bumping with uncommitted changes #1194
Description
Description
When running cz bump, committizen will include all current uncommitted changes (even if not staged) in the bump commit.
This can lead to unexpected changes suddenly being in a new release.
There should be some kind of configuration option to either abort the bumping when there are uncommitted changes (similar to bump-my-version's allow_dirty) or stash the changes, update the version, commit, and pop the stash.
Possible Solution
No response
Additional context
No response
Additional context
No response
Activity
Lee-W commentedon Aug 11, 2024
@woile I feel we could change it to add version files only in
commitizen/commitizen/commands/bump.py
Line 366 in 01fd042
marcusalstrom commentedon Oct 8, 2024
We would love to contribute to this and discussed giving the option to the user to abort if there are any unstaged changes or like @Lee-W mentioned only adding the version files to git. The issue with the latter is finding a good and convenient way of retrieving all the version file names in a general way for all the different version providers. Which approach would be considered best and if the latter do you have any tips on retrieving all the version files in a convenient way?
Lee-W commentedon Oct 10, 2024
@marcusalstrom I would vote for the latter (well, I'm biased. that's what I proposed).
would love to know how others think
woile commentedon Oct 15, 2024
I prefer having the
git.add, I wonder what's the use case for not including all modifications?If we asume commitizen runs on a CI, not on your working directory. Then you might do stuff like:
# modify a file not handled by commitizen but you want it as part of the release cz bumpBut I'm open for a non-breaking change
Note: we should also include files in
version_filesomidmme commentedon Oct 15, 2024
I think the case for not including all modifications is that unintended changes can go unnoticed. Would it in this case be better to pass a flag to bump depending on which use-case you have to try and avoid any breaking changes?
Lee-W commentedon Oct 21, 2024
sounds like a good idea to me.
I kinda forget why, but I did bumped into these a few times long ago. and it's indeed hard to notice 🤦♂️
yep, this is definitely something we need to include
bearomorphism commentedon May 9, 2026
Triage from #1964: This is a feature request, not a bug. There's no
allow_dirty-style flag in commitizen. Suggesting we relabel astype: feature. Implementation idea: a--allow-dirtyCLI flag +allow_dirtyconfig setting; when false (recommended default in v5?), error out before staging ifgit status --porcelainis non-empty (excludingversion_filesand the changelog).feat(bump): add --allow-dirty/--no-allow-dirty and allow_dirty setting