add - navbar : last tag name

[rbalet]

Describe the feature that you'd like
Having here, the last tag

Additional context (optional)
In my example, it's easy to find the last tag name, but sometimes this can be 30 - 50 commits before.
For users like my that use a CI/CD to reads the tag name to make an automatic build/publish of the project, it may be useful to always see what was the name of the previous tag, so we could directly see without having to scroll down.

[mhutchie]

Thanks for raising this feature request!

Unfortunately it can definitely not go in the top navigation bar as it already almost overflows onto multiple lines (undesirable) in multi-repo workspaces on lower resolution displays (you have the best case - i.e. high resolution display, one repo in workspace, and short branch names). The last space that is available in the navigation bar is going to be used by the upcoming filtering functionality, which will be used by a much larger number of users.

Additionally, if I added this feature to the navigation bar, I’d get numerous other requests for things other users would like in the navigation bar (all only being used by a relatively small number of users).

In a recent update I added the keystroke CTRL-H that scrolls the Git Graph View to the head commit. Instead of adding the last tag to the navigation bar, how about I add a keystroke that scrolls the view to it? This would allow you to quickly find the name of the last tag without having to take up any space on the UI.

Once the keystroke scrolls to the commit containing the last tag, I’d make the commit have some temporary emphasis (e.g. a colour flash) to draw the users eye to the specific commit. I’ve been meaning to add this to the scroll-to-head keystroke, but hadn’t got around to it yet.

[rbalet]

Hi, and thanks for the time you take to write your answer.
The problem I see with your implementation, is that, on a huge project, it will scroll to the tag, then we'll have to scroll up again the be able to add a label. (If I understand correctly).

I now have an another Idea, (I think it will be to specific to my needs, but who knows, since it's a standard it may be useful for others).

We could add here (or somewhere in the config) a list of preset autofill tag name .
And we could select a default autofill (Like v.x.x.x) that looks for the former tags and increment it, (if not found then nothing happen).

But. As said, I'll understand that this request is to specific.

[mhutchie]

I like the idea behind auto incrementing a version number, however it would require input(s) on the “Add Tag” dialog to choose whether you’re incrementing the major, minor, or patch version. The dialog is already getting quite big, so I hesitate at adding any additional inputs. As you mentioned, it is quite specific to how you operate, and I’m unsure how widely used such functionality would be.

With the solution I previously proposed, you would just have to use the keystroke CTRL-T to see what the last tag name was, then CTRL-H to scroll to the head to add the tag. You wouldn’t need to scroll manually at any point. You could also copy the name of the last tag (after pressing CTRL-T) using the existing context menu action, to be used in the new tag if you just want to increment a specific Semver field.

Instead of this, how about adding a new line of text to the “Add Tag” Dialog after “Add tag to commit xxxxxxxx:” which says “(Last tag name: )”. Then the last tag name is exactly where you need it, and you don’t need to use any keystrokes. The text could also be copied).

[rbalet]

major, minor, or patch version : is mostly patch, so when the user want a major or minor one, he could change it himself (is just an auto-completion)

The dialog is already getting quite big : I agree with you, just in the configuration of the vscode would be perfect.

unsure how widely used would be : I think quite a lot, since it's an "git standard" but I'm nobody to tell that.

CTRL-T : it's a nice solution :)

Last tag name : I'm not sure I understand, it would be here added?
(If yes, it's a nice and clean idea, since it doesn't add to much information for the user)
(Even if I'm still for an autocompletion.. *Humhum '^^)

[mhutchie]

Auto-filling the tag name based on incrementing the last named semver tag will only be used by the subset of users that:

• Use tags
• Manually add them to the local repo
• Use semver instead of a build number / arbitrary name

There are subtle variations on semver that people might use (e.g. 1.2.3 vs v1.2.3) which require different parsing code. I could see that implementing semver support in a robust way could get complicated very quickly.

To be flexible for everyone's workflows, I think an extension setting would be needed to control which of major, minor or patch is incremented.

Even if this is the case, there would be enough exceptions when the user needs to alter the auto-filled name (e.g. pre-releases, or when incrementing a different major/minor/patch field), that I think just showing the last used name would be easier and more convenient (than the user reverting the automatically incremented field, and rewriting the desired field).

---

This is a screenshot of the solution proposed in my last reply.

After mocking it up, I think it looks better as a tooltip (that sacrifices the ability to copy it though).

My preference is to go for my second screenshot for now, which I can easily include in the upcoming release.

I'll get user feedback on how widely used semver support would be, and what would be necessary to be implemented to make it save time in the real world. If the feedback is positive I'd be happy to add this in a future release.

[rbalet]

My preference also goes for the second one.
(Even If you would write it like this Last used tag: "v1.2.3").

Thx a lot and have a nice day.

[mhutchie]

This will be available in v1.22.0.

I reached out and received feedback from a range of users on the preferred tooltip message to ensure none of them found it misleading, due to the various restrictions and Git limitations this feature had to operate within.

If you'd like to use it before the next release, you can download v1.22.0-beta.4, and install it following the instructions provided here.