Configuration flag to prevent bumping with uncommitted changes

[ptoews]

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

[Lee-W]

@woile I feel we could change it to add version files only in

commitizen/commitizen/commands/bump.py

Line 366 in 01fd042

git.add(*files)

. What do you think?

[marcusalstrom]

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]

@marcusalstrom I would vote for the latter (well, I'm biased. that's what I proposed).

would love to know how others think

[woile]

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

[omidmme]

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]

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