feat: Add copy link to tag support

[alnoki]

Add Tag Support for Permalinks

Summary

This PR adds support for creating permalinks to Git tags, alongside the existing branch, commit, and default branch options. Tags provide a more readable alternative to commit hashes for versioned releases.

Changes

New Features

• "Copy Link to Selection (at current tag)" command - directly copy a link using the current tag (if HEAD is at a tag)
• "Current tag" preset option in the "choose type" quick pick dialog
• "Tags" section in the quick pick showing all repository tags
• tag option for the gitweblinks.linkType setting to use tags by default

Files Modified

• src/types.ts - Added 'tag' to LinkType and LinkTargetRef.type unions
• src/constants.ts - Added copySelectionToTag command constant
• src/settings.ts - Handle 'tag' in getDefaultLinkType()
• src/link-handler.ts - Added 'tag' case in getRef() using git describe --exact-match --tags HEAD
• src/commands/get-link-command.ts - Added "Current tag" preset and "Tags" section in quick pick
• src/commands/index.ts - Registered copySelectionToTag command
• package.json - Added command definition and 'tag' to linkType enum

Test Updates

The quick pick item indices in get-link-command.test.ts were updated to account for the new structure:

Previous structure (10 items):

• 3 presets → "Branches" separator → 3 branches → "Commits" separator → 3 commits

New structure (12 items):

• 4 presets (added "Current tag") → "Branches" separator → 3 branches → "Tags" separator → "Commits" separator → 3 commits

This shifted the branch item indices by 1 (from [4,5,6] to [5,6,7]) and commit item indices by 2 (from [8,9,10] to [10,11,12]).

Implementation Details

• Tags are retrieved using git describe --exact-match --tags HEAD for the current tag
• All tags are listed using git tag -l --format='%(refname:short) %(objectname:short) %(objectname)'
• If HEAD is not at a tag, the "Current tag" preset shows an empty description
• Tags use the same URL template as branches (the {{ ref }} placeholder contains the tag name)

[reduckted]

Hi @alnoki. Thanks for contributing, and sorry for taking so long to look at this.

I haven't given this a thorough review yet, but I do have a few concerns about tag support.

Support

The first problem is whether all providers (GitHub, GitLab, Azure Dev Ops, etc) treat tags the same way that the treat branch names. For example, VSTS uses different query parameter values for commits and branches.

GitWebLinks/shared/handlers/visual-studio-team-services.json

Line 21 in 9eb5431

"&version=G{{ type | slice:0,1 | upcase }}{{ ref | encode_uri_component }}"

In the worst case, I'm happy to restrict tag support to providers that can easily be supported.

Visual Studio

The next thing is keeping the VS Code and Visual Studio extensions in sync. This PR only changes the VS Code extension. Equivalent changes will need to be made to the Visual Studio extension. I would recommend not making those changes yet, because the changes in the VS Code extension might end up needing to change.

Performance

And lastly, there is a performance consideration. When you select a branch or commit (the commits are just the SHAs of the branches), it's limited to what branches you have in your local repository. That may not be every branch that exists in the remote, so the list is probably not huge. However, when listing tags, the list would contain every tag that exists locally. For large repositories, that could be a very large list. For example, https://github.com/renovatebot/renovate has over 11,000 tags.

Because of this performance impact, I'm not convinced that just populating the list with all tags is the right approach. I'll need to give it some more thought.

[alnoki]

@reduckted thanks for the detailed analysis! Assorted responses:

• Noted on providers using different tag styles, I'm fine with restricting to GitHub and others that support it
• I don't use Visual Studio, and won't plan on pushing any updates to it
• As for tag selection, my workflow has been to harvest links inside a repo inside of which I'm already checked out on a tag. So I wouldn't advise doing a full lookup, but rather simply use whatever tag the user has checked out - not least because trying to get a link to a different tag might break in the sense that the highlighted lines/file etc. might not even exist on a different tag that isn't checked out