Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow passing the git remote arg when opening / copying URLs for GH #105

Open
lougreenwood opened this issue Oct 3, 2023 · 2 comments
Open
Labels
enhancement New feature or request

Comments

@lougreenwood
Copy link

In my work, the git remote which I use is a fork of the repo, so when I want to view the file in GH I don't necessarily want to view the file on the default origin remote since that corresponds to my fork. Instead I might want to treat my-company-name as the canonical upstream where I would want to share a link to (it's only in rare circumstances that I actually want to share a link to my fork).

Instead, it would be useful to allow passing an arg for the git remote to create the URL for, then I can have a keybinding for opening in using some other remote.

It could also be useful to define which remote to use by default on a per-git-project basis, maybe this could be a table allowing defining a glob pattern to match to a given project or collection of projects in a parent dir Something like:

'**/code/work/**' = { default_git_remote = 'my-company-name' },
'**/code/projects/**' = { default_git_remote = 'upstream' },

This would allow overriding globally using the default commands as well as further overriding for key bindings.

I started poking around and it seems that this is the line where the URL creation happens:

local remote_url_command = utils.make_local_command("git config --get remote.origin.url")

@f-person
Copy link
Owner

f-person commented Oct 3, 2023

Would you be OK with calling Lua directly instead of getting a different behavior for the GitBlameOpenCommitURL command? If yes, we could allow passing an optional remote URL to open_commit_url and copy_commit_url_to_clipboard functions.

@lougreenwood
Copy link
Author

Sure, calling directly would be fine, but I wonder what the benefit is over extending the GitBlameOpenCommitURL would be, in both cases we'd be adding a non-breaking change and the arg would be optional. However if it were added to GitBlameOpenCommitURL the documentation for this would be in one place and easier for other users to discover.

WDYT?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants