Consider providing a gittag segment

[CaptainQuirk]

Hi there !

Thanks for your work !

Would you consider adding a segment that exposes the last git tag ?

[jaspernbrouwer]

Could you elaborate? Do you simply want to see the last tag that was created? Or the closest tag to HEAD (the checked out branch)? Or do you want to display a tag in stead of the short commit hash when in detached HEAD mode? Something else?

[CaptainQuirk]

The closest tag to HEAD would be great !

[jaspernbrouwer]

Can you describe why you want this? What is "the problem" you're trying to solve by being able to see that tag?

Ps: I'm not trying to push this request away, but I'm simply trying to determine if this is worth the work for a broader set of users, and if so, what the best way to implement it is ;)

[CaptainQuirk]

@jaspernbrouwer, I'm not trying to solve any problem in particular, just to know what is the most recent tag that was set relative to my current HEAD.

For example, I find it useful to use annotated tags to tag some code I put in production and this segment would basically display the tag corresponding to this last deployment (or for example to a preproduction environment with tags containing the string rc).

Knowing what to put as in git show <tag> would then be easier !

[jaspernbrouwer]

Thanks for the explanation, I'll see what I can do!

[abrodkin]

From my experience (I used to use some bash prompt modifier found here https://github.com/mgedmin/dotfiles/blob/master/bashrc.prompt) it is quite useful to have indication of a tag name if you're exactly on that tag.

Otherwise if I checkout tag I see something a bit useless:

~ > git > linux > afd2ff9: git status
HEAD detached at v4.4
nothing to commit, working directory clean

[jaspernbrouwer]

Done! Finally 😁

Please update using pip install --upgrade powerline-gitstatus, don't forget to add the highlight group gitstatus_tag to your colorscheme.

[abrodkin]

Well I'd say this feature is sort of half-cooked now :( Now if "show_tag" is enabled last tag in the current branch will be displayed always. For example I may have 100500 commits on top of the last tag and still last tag name will be displayed. Which is not very useful and moreover could be a bit misleading.

What I really meant was to display tag name only if we're on a pristine tag. Moreover if that's the case revision hash should be concealed (because who cares if we're already on very good identified commit).

This enhancement IMHO could be implemented quite simple:

1. Get the most recent tag name as we do it now with git describe --tags --abbrev=0
2. Get SHA of that tag with git rev-parse MY_TAG
3. Compare SHA retrieved above with git rev-parse HEAD
4. If both SHAs match then we're golden (show tag name, hide commit SHA), otherwise don't show tag name.

Any thoughts?

Indeed I may try to implement that myself but having very limited experience in Perl I may think more experienced person could be much faster with that hopefully pretty simple improvement :)

[jaspernbrouwer]

This sounds like there's demand for several features:

1. When in detached head state, replace the commit hash with the tag if that commit has a tag. If I understand correctly, this is what you (@abrodkin) are asking.
2. At any moment, show the most recent tag in the current branch (in a separate segment). Other branches may show other tags. This is what @CaptainQuirk asked for, and I have built.

As both these options need an extra git call, I want to keep them disabled by default. But I guess I could split them out in several arguments (replace_hash_with_tag and show_most_recent_tag).

I'm happy to look into into your proposition, just wanted to point out this is a different use-case.

PS: It's all Python by the way 😄

[abrodkin]

Makes perfect sense. But frankly being so egocentric I didn't realize @CaptainQuirk wanted last tag always to be displayed. Just because I don't really see a use-case for that. Probably it worth getting opinion of @CaptainQuirk on that topic so we're not just guessing.

[Thadir]

I agree with @abrodkin as it is this feature is very misleading. Any progress on this feature requet?

[jcharaoui]

I think v1.3.0 fixes the issues raised in this thread. If not, please open a new issue!

[abrodkin]

@jcharaoui I don't see either release or tag 1.3.0 are you referring to the current master branch?

[jcharaoui]

Sorry, I'm new here! Simply forgot to push tags. Did a release for v1.3.1 on GitHub and PyPI.