[feature request] Support links at commit

[raghavan-arvind]

If I have a certain commit checked out locally, I would like for this plugin to copy/open the link at that commit, if possible.

Two cases:

1. The commit checked out locally is a branch which exists in the remote, v1.2.x
2. The commit checked out locally does not exist in remote

In case 1), my proposal would be we attempt to generate link using the correct branch name, .../v1.2.x/... for readability when sending links, instead of the full commit. Find a solution which generalizes to handle main/master elegantly.

For case 2), proposal is we take merge-base between the current commit and main/master, and generate the link with this commit .../<commit>/.... Still possible for the link to point to an invalid range, but then it is on the user to ensure the code they are referencing is unchanged between the closest reference point in origin / their HEAD.

Any thoughts/concerns? If not, I can work on a PR for this change.

[raghavan-arvind]

cc: @juacker

[juacker]

Hey @raghavan-arvind , thanks for opening this. Before talking implementation I want to make sure I understand the underlying motivation, because it changes what the right behaviour is.

My read: you're usually on a local feature branch that isn't pushed yet, you want to share a snippet with a colleague, and today the plugin emits .../<your-local-branch>/... which 404s for them. So what you actually want is for the plugin to fall back to some ref the remote already knows, so the link works for the recipient, so your proposal is really asking for "the closest commit the remote definitely has."

Is that the actual use case, or were you thinking of something more like a GitHub-style permalink (the y shortcut) where the link is pinned to the exact commit you're viewing?

[raghavan-arvind]

Thanks for the response!

So what you actually want is for the plugin to fall back to some ref the remote already knows, so the link works for the recipient, so your proposal is really asking for "the closest commit the remote definitely has."

Yes exactly! This is what I had in mind. That's one use case, local feature branch.

Now imagining we are on a branch which exists on the remote, second use case:

were you thinking of something more like a GitHub-style permalink (the y shortcut) where the link is pinned to the exact commit you're viewing?

We have two options here:

1. Give URL with the full commit sha of that branch -- permalink
2. Attempt to use a branch tag master, v1.2, etc.

I've historical had some vimscript to do 1) always give the closest permalink pinned to sha. 2) is closer to what this repo does.
Issue is that branches are mutable, so if we want to provide permalinks, it depends on the repo owner whether link-by-branch-name is mutable, i.e. master wont be, but v1.2 should be.

Curious to get your take on expected behavior, if we are on master would you prefer the plugin default to create a link to master or a permalink? I lean permalink if we are on master but the branch name if we are on a versioned branch v1.2, 1.2-rc-0 (also usually permalink, but more readable). For my usecase I'm usually pointing to a specific LOC and even when referencing a file, I still usually want a permalink, in case it's removed or renamed