ValueError: invalid literal for int() with base 10: 'g41e1dd17c20e81324102c859b89761b8e2f2f666'

[umazalakain]

bumpversion tries to convert the latest git rev hash to an int:

Traceback (most recent call last):
  File "/home/shokah/.virtualenvs/TPB/bin/bumpversion", line 9, in <module>
    load_entry_point('bumpversion==0.3.6', 'console_scripts', 'bumpversion')()
  File "/home/shokah/.virtualenvs/TPB/local/lib/python2.7/site-packages/bumpversion/__init__.py", line 243, in main
    vcs_info.update(vcs.latest_tag_info())
  File "/home/shokah/.virtualenvs/TPB/local/lib/python2.7/site-packages/bumpversion/__init__.py", line 85, in latest_tag_info
    info["distance_to_latest_tag"] = int(describe_out.pop())
ValueError: invalid literal for int() with base 10: 'g41e1dd17c20e81324102c859b89761b8e2f2f666'

[peritus]

Sounds like I need to do a bugfix release today. Thanks.

Any pointers how to reproduce this?

Sent from my pocket calculator

On 03 Jan 2014, at 21:43, Unai Zalakain notifications@github.com wrote:

bumpversion tries to convert the latest git rev hash to an int:

Traceback (most recent call last): File "/home/shokah/.virtualenvs/TPB/bin/bumpversion", line 9, in load_entry_point('bumpversion==0.3.6', 'console_scripts', 'bumpversion')() File "/home/shokah/.virtualenvs/TPB/local/lib/python2.7/site-packages/bumpversion/init.py", line 243, in main vcs_info.update(vcs.latest_tag_info()) File "/home/shokah/.virtualenvs/TPB/local/lib/python2.7/site-packages/bumpversion/init.py", line 85, in latest_tag_info info["distance_to_latest_tag"] = int(describe_out.pop()) ValueError: invalid literal for int() with base 10: 'g41e1dd17c20e81324102c859b89761b8e2f2f666' \ Reply to this email directly or view it on GitHub.

[umazalakain]

I investigated a bit and turns out this arises when I try to bump version in a git repository with staged but uncommitted changes.

I know this situation looks a bit weird at first but imagine the (fairly normal) situation where you want to version bump while recording the changes in some changeset file. Well, you want to do it all in one single commit. The only way of doing it now is with posterior commit squashing.

I am somewhat uncertain about what solution to use. I guess some parameter could be included in config and CLI while, if not defined, asking a question when staged but uncommitted changes are found (i.e. "Staged uncommitted changes have been found, would you like to commit them along with the version bump? [y/N]").

On a different matter, this project looks certainly appealing to me, I think I'll try to invest some time into it ;-)

[peritus]

There's three aspects to this:

First, the stacktrace you posted. Given this git repository status (with a staged but uncommited files):

vagrant@bumpversion-dev:~/issue33test$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   new file:   staged-but-uncommitted.txt
#

gives

vagrant@bumpversion-dev:~/issue33test$ bumpversion patch --new-version 13
Traceback (most recent call last):
  File "/usr/local/bin/bumpversion", line 9, in <module>
    load_entry_point('bumpversion==0.3.6', 'console_scripts', 'bumpversion')()
  File "/usr/local/lib/python2.7/dist-packages/bumpversion/__init__.py", line 368, in main
    vcs.assert_nondirty()
  File "/usr/local/lib/python2.7/dist-packages/bumpversion/__init__.py", line 55, in assert_nondirty
    b"\n".join(lines))
AssertionError: Git working directory not clean:
A  staged-but-uncommitted.txt

on my machine, because at the moment bumpversion simply aborts when there is a dirty working directory (yes, I certainly want to lift that restriction in the future).

I wonder what you did to get past that.

2)

The affected part of the code tries to split the git describe output (for example

[torvalds@g5 git]$ git describe parent
v1.0.4-14-g2414721

(see https://www.kernel.org/pub/software/scm/git/docs/git-describe.html)

in "version number", "distance to last tag" and "revision sha1". Somehow that fails and it tries to parse "revision sha1" where it expects "distance to last tag".

3) About using bumpversion in dirty repos:

I certainly want to support workflows where bumpversion doesn't do this one atomic operation where it increases version numbers, creates commits and tags and everything in one command but where you can execute parts of that one after another (so that your other scripts for grooming changelogs, doing whatever you do when doing a release can run in between any of these steps).

It's not there yet, patches are welcome.

[peritus]

Any hints on how to reproduce this ?

Closing this for now, PLEASE re-open with information on how to reproduce this.