commitizen icon indicating copy to clipboard operation
commitizen copied to clipboard

[Bug] Bump commits ALL files

Open nbrugger-tgm opened this issue 4 years ago • 5 comments

Description

Instead of committing just all files containing a version ALL changed files are committed (new ones are not just changed ones). This is not good if a change is not meant to be included in the release.

While this can be avoided by branching it should still behave different as git add . and git commit <whatever> is very carelessly.

Steps to reproduce

  1. Create repo and add cz config file
  2. Add file1.txt and file2.txt
  3. stage and Commit file1
  4. cz bump (Behaves as expected)
  5. Commit the adding of file2
  6. Change the content of file1 and don't stage it
  7. cz bump

You will see that all changes of file1 are commited in the bump: 0.0.1 -> 0.0.2 commit

Desired behavior

When executing a cz bump

  1. Stash the changes and added files (staged and unstaged the same)
  2. Warn the user if he has Staged files because they will be merged with the unstaged ones when stashing
  3. Execute the bump
  4. Pop the stash
  5. Delete the stash

Environment

  • commitizen version:2.13.0

  • python version:Python 2.7.17

  • operating system:Linux

nbrugger-tgm avatar Feb 12 '21 00:02 nbrugger-tgm

I'm not sure we'll fix this, for me is working as desired, and it would involve quite some work. Sorry.

First, it's not doing git add ., this would include untracked files, I would consider this dangerous. It is doing git add -a, which includes (as you said) not staged files, but which are being tracked, excludes untracked.

I delegate responsibility of this to the developer, if you don't want this to happen either create a commit or stash before doing a bump.

For me it also works as a feature, because I'm allowed to include other changes into the bump commit, cheaply without having to manually add them (if they are being tracked already).

Would it help if this behavior is documented?

An alternative implementation without using stash:

  1. Remove -a from git add
  2. Run git add for the config file + the files included in version_files
  3. If the user has manually run git add <files> they would also be included

Again, I don't have plans to fix this, but contributions are welcome 👍🏻

woile avatar Feb 19 '21 11:02 woile

What do you think about "auto stashing" where bevore any changes are written a stash is created and after the bump the using stash pop to restore pre-bump state.

This would also be in line with your "future plans" so you don't have to add files manually. Would such a contribution / PR be accepted? Maybe adding an option/setting to enable or disable auto stashing would be useful.

The "feature" at the moment not being documented is less of a problem for me but ist just one sentence so maybe worth it.

nbrugger-tgm avatar Feb 19 '21 15:02 nbrugger-tgm

The "auto stashing" option sounds good to me as long as we do not set it as the default behavior. If we'd like to do so in the future, we'll need to bump a major version

Lee-W avatar Feb 20 '21 02:02 Lee-W

I'm in as a positional argument as well. I'd like to see an implementation 👍🏻

woile avatar Mar 05 '21 13:03 woile

Sadly my python skills are quite limited. If it was a language i am actually active in (Java, TS, C#) i could contribute.

nbrugger-tgm avatar Nov 29 '21 18:11 nbrugger-tgm

Closing as the current behavior works well enough

woile avatar Apr 28 '23 13:04 woile

Would it help if this behavior is documented?

Yes! I was a bit thrown off by this behaviour and ended up here because it is not intuitive at all that files are committed outside of the commit command.

loelkes avatar Mar 12 '24 20:03 loelkes