Repository info for gitblame.commitUrl

[Fidge123]

Please provide the repository name (and other repository info if known) for the gitblame.commitUrl setting. Using that it would be possible to set the setting globally instead of per project.

[Sertion]

I like this idea, but it would still require project specific settings as there is not a repository name or a project name concept in git.

We might be able to use the remote.origin.url config option but it does not respect users that do not call their origin origin and will have to make assumptions about how the URL is structured.

Do you have an idea on how to find this information or why a new config specifically for project would be helpful?

[Fidge123]

I got the idea from a similar atom plugin ( https://github.com/alexcorre/git-blame ), maybe you can find some helpful information there.

These might be helpful: https://github.com/alexcorre/git-blame/blob/master/lib/util/RemoteRevision.js#L89 https://atom.io/docs/api/v1.17.2/GitRepository#instance-getOriginURL

I couldn't find how to do the same thing in vscode, but you might know a bit more :)

[Sertion]

They have implemented in a way that only works for Github and Bitbucket and therefore make a lot of assumptions about what data is available and what format that data has.

[sabrehagen]

Maybe you could design it so each language has a plugin? E.g. a package.json file in the npm ecosystem has the repository field which contains the url of the repository. This would be very useful for navigating to the web interface displaying the commit.

[henvic]

Hey, I just had this issue as well and I find the plugin would be way more useful with an auto-discovery configuration. Not sure how it should work, though.

One alternative:

1. Assume most users of your plugin use GitHub, Bitbucket, and Gitlab, and only support auto-discover for those
2. Try to infer the address from 'origin'
3. Try to infer it even if user is using SSH/git, instead of HTTPS for their remote addresses

e.g.,

$ git remote -v
henvic  git@github.com:henvic/cli.git (fetch)
henvic  git@github.com:henvic/cli.git (push)
origin  git@github.com:wedeploy/cli.git (fetch)
origin  git@github.com:wedeploy/cli.git (push)
alternative /Users/henvic/projects/alt/cli (fetch)
alternative /Users/henvic/projects/alt/cli (push)

I myself don't use 'origin' as a remote for my preferred 'upstream' remote always, but this approach would serve me well most of the times. And I would make auto-discovery default.

By the way, if you don't do something GitHub-friendly I think it is risky. I say this as a maintainer of node-gh who passed by a similar situation in the past (with a Jira integration, if I remember correctly), where I didn't want to compromise with heuristics, and ended up hearing many complaints and co-workers telling me they stopped using the tool I maintained for some tasks because it was just too complicated (even though it isn't -- lol).

[Sertion]

If someone is interested in investigating how we could proceed to do this I would welcome all the help I can get. Knowing if there is a standardised path for viewing commits would help immensely.

[neerolyte]

https://github.com/ziyasal/vscode-open-in-github/blob/master/src/gitProvider.js seems to manage ok.

I work across GitHub and GitLab and it copes ok.

I've also tested renaming my remote to asdf and it managed to generate the right URL after a restart still.

[neerolyte]

If you want to keep it as config rather than code-with-assumptions providing some option to configure the default remote that by default is just set to origin (this is what git uses, it's a sane default) and if the default remote is missing, just falling back to the first remote should get a usable remote "enough" of the time. Otherwise providing an ordered list of remotes to try e.g ["origin", "upstream", "default", "foo"] would work too.

Having the ability configure a regex to run over the remote URL would help most people too, e.g /^(git@|https:\/\/)([^:\/]+)[:\/](.*)\.git$/ parses the GitHub and GitLab remotes well enough to just substitute the URL as https://$2/$3/commit/$commitid. Bit Bucket needs an "s" on the end of "commit".

[Sertion]

A simple version of this has been added in 2.3.0