commitizen-tools
Configuration flag to prevent bumping with uncommitted changes
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
@woile I feel we could change it to add version files only in https://github.com/commitizen-tools/commitizen/blob/01fd0426677b4db07988103d3a0ebd0d10763886/commitizen/commands/bump.py#L366. What do you think?
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?
@marcusalstrom I would vote for the latter (well, I'm biased. that's what I proposed).
would love to know how others think
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 bump
But I'm open for a non-breaking change
Note: we should also include files in version_files
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?
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?
sounds like a good idea to me.
I prefer having the git.add, I wonder what's the use case for not including all modifications?
I kinda forget why, but I did bumped into these a few times long ago. and it's indeed hard to notice 🤦♂️
Note: we should also include files in version_files
yep, this is definitely something we need to include