@warner I've been using this in a lot of places recently and have found it really useful. I believe being able to change how a version is rendered on a branch basis is a critical feature for versioneer.

How do you feel about this PR? It is worth knowing up front if this isn't going to fly, but if in principle you agree, but not necessarily with this implementation, I'd be happy for this branch to be used as a basis for further development.

👍

@warner - is there any value in me rebasing this and getting the tests passing? Ideally I'd like to know if you are in favour of the change before I commit too much more time to it...

Hey, sorry for the delay.

Yeah, I think having branch names could be useful. There are a lot of cases where we can't get that data (git checkouts have the most information, git-archive tarballs have a lot less).

One thing I'm worried about is that the data can be pretty incomplete at the best of times. In your example (that graphic is awesome BTW), git will tell us the current checked-out branch, but it's not clear that the "v2.1.dev3" revision shouldn't be named "v1.1.post1" instead.

To get that right will require some sort of SemVer comparison routine (like, find all reachable tags, compare them to find the "highest", then compute a distance from that one). As I mentioned in #110, that's only going to be possible from a git checkout, and sounds kind of hairy, and possibly a performance concern (doing O(len(tags)) git operations on each invocation of the target program).

But I'm at least up for adding data about the currently-checked-out branch name. Maybe we should define a "style" that uses this data, so users only pay the performance penalty if they've opted-in for it?

Thanks @warner - I will try to pull this into a healthy state over the next few weeks. (I'll ping once I think it is time to take another look).

but it's not clear that the "v2.1.dev3" revision shouldn't be named "v1.1.post1" instead

I agree. I had to prioritise master for this reason:
https://github.com/warner/python-versioneer/pull/90/files#diff-2919761638c150740281b8326953b713R59

I completely agree with your wariness of taking this as a sliver bullet - there are gnarly cases which make the branch based rendering complex (and hard to test). I have been using this in earnest for a good year now - and in spinning this back up, I'll be taking it for a thorough road test.

Thanks for your support @warner

what about using a more plugin style / optional install path for this ..?

Hey folks, I notice this and pr #89 both tried to add branch as a piece or version but stopped just short of merging without any apparent resistance. I comment on this PR just as it's slightly more recent but is there any reason these have sat rusting? Can I help in some way?

I'm also interested in including the branch name when the tip of the branch is not a tag.

Updated to work with latest master #174

Closing in favour of #174.