Allow more customization of domain based on remote

Fuco1 commented 4 years ago

I'm using a remote host mycompany.github.com which is set in my ssh config to resolve to github.com:

Host mycompany.github.com
    HostName github.com
    # User git
    IdentityFile ~/.ssh/id_rsa_mycompany
    IdentitiesOnly yes

This enables me to use multiple different ssh keys with git easily.

Currently when I run browse-at-remote it navigates to mycompany.github.com which does not exist. I would like to have some option of explicitly specifying the base host for a remote. I suspect extending browse-at-remote-remote-type-domains with a third option might do the trick, or even migrating the simple cons to a plist so there is more options to customize it in the future.

We can of course keep the current data structure for backwards compatibility. So my entry ("mycompany.github.com" . "github") would turn into (:domain "mycompany.github.com" :type "github" :base "github.com").

Another option is to introduce a second configuration, but that feels like duplication (having the same "primary key" in two places).

Let me know what you think!

arichiardi commented 3 years ago

Hi there, I would like to add a +1 to this one.

In my case the git remote shows up as:

origin git@ssh.dev.azure.com:...

However the actual http domain is

https://dev.azure.com/...

I was actually thinking of adding an azure remote but this is a bit of a blocker.

theherk commented 2 years ago

I'm in a similar situation where we use a proxy to reach git remotes. For example, remote ssh://git@git.foo.net/proj-a/repo-x.git is browsed via url https://bitbucket.bar.baz.com/projects/proj-a/repos/repo-x. This would be complex to configure, but since it is just privately hosted bitbucket, it seems maybe others would benefit from it.

cpaulik commented 1 year ago

Has anybody found a solution for this problem? I'm in the same boat here.

rmuslimov commented 1 year ago

@Fuco1 @arichiardi @theherk @cpaulik sorry for belated reply to this thread. Please take a look for latest PR from @ilmotta which is implementing this feature.

theherk commented 1 year ago

@rmuslimov: Thank you. It still doesn't seem to work for me, but I'm guessing I have it configured incorrectly or my situation is not covered by this change. I have installed d81643c9 and configured with:

  (add-to-list 'browse-at-remote-remote-type-regexps
               `(:host ,(rx bol "git.foo.net" eol)
                 :type "bitbucket"
                 :actual-host "bitbucket.bar.baz.no")))

The above statements still being the case:

remote url: ssh://git@git.foo.net/proj-a/repo-x.git
browsed at: https://bitbucket.bar.baz.com/projects/proj-a/repos/repo-x

I have an ssh configuration like this in ~/.ssh/gproxy.cfg:

Host gproxy2
        Hostname gitproxy.bar.cloud
        LocalForward 9009 git.foo.net:22
        ControlMaster auto
        ControlPath ~/.ssh/sockets/%r@%h:%p
        Port 443
        User git

Host git.foo.net
        HostName localhost
        StrictHostKeyChecking no
        Port 9009

and in git configuration:

[core]
    sshCommand = ssh -F ~/.ssh/gproxy.cfg

Let me know if I should try any other configuration. No big deal either way; I don't think this is a common setup.

ilmotta commented 1 year ago

Hey @theherk, thanks for trying out the latest release.

The README is hinting on the idea of helping users who use custom SSH config files, but behind the scenes the implementation in browse-at-remote is actually quite direct and limited.

When you call the Emacs command browse-at-remote it is translating git.foo.net to bitbucket.bar.baz.no, and it's not reading your ~/.ssh/gproxy.cfg file. From your example SSH configuration, it seems browse-at-remote should translate git.foo.net to localhost:9009, right? If that's the case, then the configuration below should work:

(add-to-list 'browse-at-remote-remote-type-regexps
             `(:host ,(rx bol "git.foo.net" eol)
               :type "bitbucket"
               :actual-host "localhost:9009"))

Is this an acceptable solution for your use case?

theherk commented 1 year ago

I provided much of that for context not knowing the implementation, but it seems to me the only bits that should matter are the remote ssh://git@git.foo.net/proj-a/repo-x.git and the translated address https://bitbucket.bar.baz.com/projects/proj-a/repos/repo-x. At that url I can reach the repositories web interface. So I feel this should be correct:

(after! browse-at-remote
  (add-to-list 'browse-at-remote-remote-type-regexps
               `(:host ,(rx bol "git.foo.net" eol)
                 :type "bitbucket"
                 :actual-host "bitbucket.bar.baz.no")))

But I still get the foo address rather than the bar.baz.no address. It doesn't seem to translate at all, so maybe my matching is incorrect?

ilmotta commented 1 year ago

@theherk, I tried to reproduce this problem in a test repo, but it seems to work. If you follow the same steps below, does it work for you?

I changed the repo's .git/config to use the remote you shared:

[remote "origin"]
    url = ssh://git@git.foo.net/proj-a/repo-x.git
    fetch = +refs/heads/*:refs/remotes/origin/*

Then update the variable in Emacs. Notice I used setq here to make sure the variable contains a single rule for git.foo.net, just to make things more reproducible.

(setq browse-at-remote-remote-type-regexps
      `((:host ,(rx bol "git.foo.net" eol)
         :type "bitbucket"
         :actual-host "bitbucket.bar.baz.no")))

Then the command browse-at-remote opened my browser at https://bitbucket.bar.baz.no/proj-a/repo-x/src/.

theherk commented 1 year ago

@ilmotta Hmm, it doesn't.

Here is the output of describe variable:

browse-at-remote-remote-type-regexps is a variable defined in
browse-at-remote.el.

Value
((:host "^git\\.foo\\.net$" :type "bitbucket" :actual-host "bitbucket.bar.baz.no"))

Original Value
(("^github\\.com$" . "github")
 ("^bitbucket\\.org$" . "bitbucket")
 ("^gitlab\\.com$" . "gitlab")
 ("^git\\.savannah\\.gnu\\.org$" . "gnu")
 ("^gist\\.github\\.com$" . "gist")
 ("^git\\.sr\\.ht$" . "sourcehut")
 ("^.*\\.visualstudio\\.com$" . "ado")
 ("^pagure\\.io$" . "pagure")
 ("^.*\\.fedoraproject\\.org$" . "pagure")
 ("^.*\\.googlesource\\.com$" . "gitiles"))

Here is the remote value in .git/config:

[remote "origin"]
    url = ssh://git@git.foo.net/proj-a/repo-x.git
    fetch = +refs/heads/*:refs/remotes/origin/*

Perhaps I am calling the wrong command. My options and outcomes are:

browse-at-remote: yields browse-at-remote--get-remote-type: Wrong type argument: stringp, :host
browse-at-remote-homepage: opens https://git.foo.net/proj-a/repo-x

ilmotta commented 1 year ago

Yeah @theherk, that's weird because your settings look correct. Thanks for giving another try. I would like to debug your problem, but unfortunately I can't reproduce it, i.e. browse-at-remote always opens https://bitbucket.bar.baz.no/proj-a/repo-x/src/, which is what you want.

You seem to be calling the correct command browse-at-remote, but I don't have the command browse-at-remote-homepage available. I tried to find browse-at-remote-homepage in older versions of the package, but it's not there. I checked out the same commit as you https://github.com/rmuslimov/browse-at-remote/commit/d81643c975e77d506fe2eb931229739c162adb5d, but the source code doesn't have that command.

I see you used the macro after!, which often comes from Emacs Doom. Do you (or Doom) happen to have more customization on top of the browse-at-remote package? That could explain the existence of the command browse-at-remote-homepage.

It would be helpful if you could provide a clean config that I can run and debug with emacs -Q.

theherk commented 1 year ago

@ilmotta Thank you for helping me out. This is no big deal, and at this point I'm pretty sure my configuration is the issue. I shall attempt this with a clean configuration, but I'm confident it will work in as it has for you. It must be something about doom.

I installed the package via straight with:

(unpin! browse-at-remote)
(package! browse-at-remote :recipe (:host github :repo "rmuslimov/browse-at-remote"))

I'm sorry for the trouble. I'm actually a bit of an embarrassment to the community with my heavy reliance of config systems and not really knowing how to debug issues like this very well. 😆

Perhaps I'll follow up down the road, but I think we can safely assume this is a me issue.

ilmotta commented 1 year ago

Glad to help @theherk :)

I'm actually a bit of an embarrassment to the community with my heavy reliance of config systems

No embarrassment at all! Lots of people in the Emacs community (including myself) use Doom as a source of inspiration to tweak/optimize some things. And thanks for reporting the problems you found.

Perhaps I'll follow up down the road, but I think we can safely assume this is a me issue.

A couple things you could try in the future:

Call find-library > browse-at-remote. See the source code, double-check it's the latest.
Check if you have stale data, maybe clean-up straight's build directory and build cache file.
If you're relatively comfortable with Emacs Lisp, you can try debugging some browse-at-remote functions by calling edebug-defun. This could help you quickly pinpoint what's going on.
Call describe-function > browse-at-remote-homepage. See who's defining that, what it does. This function is suspicious because it isn't implemented in the package, so maybe your Emacs is actually using a different package (?)

cpaulik commented 1 year ago

@ilmotta @rmuslimov Thank you so much for fixing this. It works great for me and is such a time saver :pray:

rmuslimov / browse-at-remote

Allow more customization of domain based on remote #70