Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tests fail against git-1.8.3 #11

Closed
warner opened this issue Aug 21, 2013 · 1 comment
Closed

tests fail against git-1.8.3 #11

warner opened this issue Aug 21, 2013 · 1 comment

Comments

@warner
Copy link
Collaborator

warner commented Aug 21, 2013

They worked against git-1.8.2.3 (and earlier), but fail when run with git-1.8.3 (and later).

FAIL: test_full (__main__.Repo)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test/test_git.py", line 115, in test_full
    self.do_checks(short, full, dirty=False, state="SA")
  File "test/test_git.py", line 167, in do_checks
    self.check_version(target, exp_short_TD, exp_long, False, state, tree="TD")
  File "test/test_git.py", line 201, in check_version
    self.compare(v, exp_short, state, tree, "RA")
  File "test/test_git.py", line 189, in compare
    % (where, got, expected))
AssertionError: SA/TD/RA: got 'bcf1f672131090156fb30bd9597799cb73d68693' != expected '1.0'
@warner
Copy link
Collaborator Author

warner commented Aug 21, 2013

It looks like the guilty git commit was git/git@e52e6f7 which changed pretty.c to use the format_decoration() from log-tree.c instead of its own. This function is used when expanding $Format:%d in the _version.py file, when making a tarball with git-archive. They combined these to take advantage of new color-hilighting code (shared between 'git log --decorate' and other places that can show these decorations). The git-1.8.2.3 version expands $Format:%d$ into (HEAD, demo-1.0, master), whereas the git-1.8.3 code expands it to (HEAD, tag: demo-1.0, master).

https://github.com/warner/python-versioneer/blob/master/src/git/middle.py#L33 then parses this list. It looks for tags by recognizing a configurable prefix (in this case, demo-). The new tag: string prevents the match from happening, so the parser concludes there are no tags, and falls back to using the full revision hash.

warner added a commit that referenced this issue Aug 21, 2013
Git-1.8.3 introduced a change to the way "$Format" strings (specifically
the "%d" variable) are expanded in git-archive -generated tarballs. The
list of refs has always included both branch names and tags. But in
older versions, tags were not emitted any differently than branch names:
the list might say:

 (master, HEAD, v1.0)

Starting in 1.8.3, tags are marked with a distinctive "tag: " prefix, so
you get:

 (master, HEAD, tag: v1.0)

The versioneer code that deduces version tags from generated tarballs
was not spotting the newly-marked tags, and falling back to reporting a
full SHA1 hash as the revision, instead of the intended tag name.

This change fixes the parser and restores compatibility with newer
versions of git. Closes: #11.
@warner warner closed this as completed Aug 21, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant