I like to use vc-revision-other-window to checkout old versions of a file in emacs. It would be awesome if git-link understood what was happening in this case and would like to the appropriate revision/filename when I use it from one of these buffers.

If we have no branch and git-link-use-commit is nil we'll get an empty path segment, e.g., path//foo. Under these circumstances we should should signal a "cannot figure out what to link to" error and not return a link.

Something like this would be golden for code review, I assume just needs some git blame + git-commit-link plumbing?

A way to get a links from git grep output or a *grep* buffer.

Hi,

If I have multiple remotes, I'd like to choose from a particular one to construct the link.

What do you think of this feature request?

Given my ~/.gitconfig has:

[url "[email protected]:"]
	insteadOf = gh:

and I do git clone gh:sshaw/git-link, open git-link/git-link.el and run M-x git-link, I get the error message No handler found for gh

This is because git-link--remote-url calls git config remote.{name}.url which returns the raw URL.
Instead it should be calling git remote get-url {name}, which resolves insteadOf directives.

This version works for me:

(defun git-link--remote-url (name)
  (car (git-link--exec "remote" "get-url" name)))

The git config --get has the proper URL for a remote:

git config --get remote.origin.url
[email protected]:grpc/grpc-web.git

But when invoked the gitlink command in emacs, it writes the error message:
Remote ‘origin’ not found

At some point in the last year or two, github changed their URLs for branches with a / in their name. The slash now appears literally in the URL. The URL path that git-link generates, with %2F, resolves to a 404. git-link should avoid url-hexify in this case.

I have not checked what is needed for other git hosting providers, nor what providers git-link aims to support.

I just installed git-link from melpa (version 20220206.1802).

When doing M-x git-link in a git repo I get mapconcat: Wrong type argument: arrayp, (47 97 98 99 100 101 102 103 104 105 ...)` in the minibuffer.

Here is the stack trace:

Debugger entered--Lisp error: (wrong-type-argument arrayp (47 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 ...))
  #f(compiled-function (byte) #<bytecode 0x3142aa9>)(98)
  mapconcat(#f(compiled-function (byte) #<bytecode 0x3142aa9>) "blobd/topology/zookeeper_topology.go" "")
  url-hexify-string("blobd/topology/zookeeper_topology.go" (47 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 ...))
  git-link("origin" 103 nil)
  funcall-interactively(git-link "origin" 103 nil)
  call-interactively(git-link)
  (lambda nil (interactive) (call-interactively (intern (ido-completing-read "M-x " (all-completions "" obarray (quote commandp))))))()
  funcall-interactively((lambda nil (interactive) (call-interactively (intern (ido-completing-read "M-x " (all-completions "" obarray (quote commandp)))))))
  call-interactively((lambda nil (interactive) (call-interactively (intern (ido-completing-read "M-x " (all-completions "" obarray (quote commandp)))))) nil nil)
  command-execute((lambda nil (interactive) (call-interactively (intern (ido-completing-read "M-x " (all-completions "" obarray (quote commandp)))))))

Do you have an idea to solve it ?
Thanks

EDIT:

Changing this line

to (url-hexify-string filename) works for me (it doesn't crash anymore and I get a valid github link)

I think this was intended to do the check, but for a file that exists in a repo that is not part of the repo, branch is "" and commit is a SHA, resulting in a link with a missing path segment:

https://github.com/sshaw/git-link/tree//xxx#L1

Sometimes I need to have http instead of https in the links. Currently I deal with this using

(use-package git-link
  :ensure t
  :bind ("C-c g l" . git-link)
  :config
  (setq git-link-open-in-browser t)
  (defun git-link--http-advice (func link)
    (funcall func (replace-regexp-in-string "^https:" "http:" link)))
  (defun git-link-toggle-http-advice ()
    "Toggle using http or https by advicing `git-link--new'."
    (interactive)
    (if (advice--p (advice--symbol-function 'git-link--new))
	(advice-remove 'git-link--new 'git-link--http-advice)
      (advice-add 'git-link--new :around 'git-link--http-advice)))
  (git-link-toggle-http-advice))

But clearly there is a better way to deal with this. It seems to me that it is trivial to support this in the code (e.g., by adding a variable instead of hard-coding https in the links).

Hi
I run my own git ( 'Gitea' server ) ... which is becoming a more and more popular 'self-hosted' option !
that would be great to enjoy git-link there too

thX thX thX

https://github.com/sshaw/git-link/blob/master/git-link.el#L457
For sourcehut (git.sr.ht) used the same function as for github, but it generates a link using https://%s/%s/blob/%s/%s pattern, while for sourcehut it should be https://%s/%s/tree/%s/%s, because /blob/ provides access to raw file, while /tree/ has ability to show exact part of the code using fragment part of address.

As it is right now:
https://git.sr.ht/~abcdw/rde/blob/master/rde/system/install.scm#L50

As it should be:
https://git.sr.ht/~abcdw/rde/tree/master/rde/system/install.scm#L50

Travis CI is total shit now. Takes hours to run.

first, thanks for this package!

that said, please use (user-error ...) instead or (message ...) to signal errors, so that i can catch them and do something sensible.

this would allow me to write a function that would first try (git-link-commit), falling back to (git-link) in case that fails, which would basically "do what i mean" in 99% of my use cases.

let me know whether i should submit a pr!

Using a branch name is fragile because it can break if the branch is updated to point to a new sha. Seems like it would be nice to use git rev-parse HEAD to link to the current ref (which is immutable and therefore less fragile).

...instead of defvar. this makes for easier discoverability.

I often have several remotes where none are named origin; but there's typically one that's the tracking remote for that branch.

When called with no prefix arg, it'd be nice to default to the tracking one; if there's no tracking remote, then try origin if possible; if not, just pick one of the remaining possibilities.

Hi,

In the name of extensibility, I'd like to request a macro or way of creating my own handler easily for a custom git forge.

For example I tried to use git-link on this forge and it failed:

https://git.cyberia.club/cyberia/capsul-flask

Hi,

When I try to select a region and call git-link-commit, I get the error

Point is not on a commit hash

Instead of that, can you return the link to the selected lines from the latest commit?

Most of the time, I need to send reference to a piece of code from my master (latest commit). But that code might change in the future and the line references might change. So I prefer to link to the links in that specific commit even if that's the master.

Thanks for the very valuable package. I appreciate your work.

One issue I came across was that the package does not support opening the file in the browser. Typically, I have 3 cases when I open a file in the browser:

1. Selecting a single line. This means that start=the selected line, and end=nil
2. Selecting a region. This means that start=first line of the region, and end=last line of the region
3. The file (with no selection). In such case, the start=line of the cursor, and end=nil

there is not way to distinguish 1 from 3. If I want to point a given file (no single region selected) to a collaborator, I won't be able to do that without losing (1).

I don't know if this is something you are interested in supporting.

I had this in my gitconfig:

[remote "origin"]
    url = [email protected]:CestDiego/spacemacs
    fetch = +refs/heads/*:refs/remotes/origin/*

And while normally it works for other purposes such as pulling and other things, git link thinks that it's a url and tries to link me to a http://[email protected]/CestDiego/Spacemacs which of course doesn't have a handler and then errors out by saying, no handler for git@github

Can we configure default remote (origin/upstream) (& branch also) at repository level. For certain upstream repositories, I want to see commit links in upstream though I am in origin. Usecase for forked codebases. Upstream is pointing to source while origin is pointing to my fork which may be outdated.

The git-link interactive function requires 3 params is seems which works somehow when calling M-x git-link.

How do you correctly call git-link from another interactive function in order to use the resulting url?

When git-timemachine is active and say, git-link-use-timemachine is set, git-link should link to the revision currently being viewed in the time machine.

(and (featurep 'git-timemachine) (car git-timemachine-revision))

TODO: is it correct to depend on git-timemachine-revision? Is there something else?

In my company, we host our Gitlab instance over bare HTTP, not HTTPS.

What about adding a variable to customize URLs with regards to the HTTP protocol?

Request for a function git-link-gitiles

Gitiles - A simple JGit repository browser
Gitiles is a simple repository browser for Git repositories, built on JGit. Its guiding principle is simplicity: it has no formal access controls, no write access, no fancy Javascript, etc.

https://gerrit.googlesource.com/gitiles/

Example file in Gitiles: https://gerrit.googlesource.com/gitiles/+/refs/heads/master/java/com/google/gitiles/DateFormatter.java

The README states that git-link works with VC revisions, but a URL generated from a buffer created by log-view-find-revision returns 404 error on Github.

Reproduce steps:

1. C-x v l in a git tracked file/buffer
2. f on a commit
3. A buffer named FileName.php.~adcfbddbc26784c5f6dbd9e1860e4afee58f013a~ is generated
4. M-x git-link

Result:

https://github.com/[org]/[repo]/blob/bugfix%2Fab%2318867/src/[redacted]/[redacted]/[redacted]/FileName.php.~adcfbddbc26784c5f6dbd9e1860e4afee58f013a~#L1

Visiting the generate URL goes to a 404 - page not found on Github.

Expected:

https://github.com/[org]/[repo]/blob/af469d650ba1a823f9a8b390399d7f8dd9956e76/src/[redacted]/[redacted]/[redacted]/FileName.php#L1

A working URL like the ones from git-timemachine and magit generated buffers.

System version:
GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0) of 2023-02-23, modified by Debian
Description: Debian GNU/Linux 11 (bullseye)

It would be great if this package could deal with tramp-mode filenames that look like /ssh:aws-dev:/home/ubuntu/somedir/main.go
When I called git-link I get the message Can’t figure out what to link to

what i did

for reference

assuming i have the following in my ~/.ssh/config

Host git-1
    HostName github.com
    IdentityFile ~/.ssh/1/id_rsa
Host git-2
    HostName github.com
    IdentityFile ~/.ssh/2/id_rsa
Host git-3
    HostName github.com
    IdentityFile ~/.ssh/3/id_rsa
#... etc...

and a git repo with the following in its .git/config

[remote "origin"]
	url = ssh://git-1:org/repo.git

use git-link

what happened

no handler for git-1 :(

what i want

link to github.com/org/repo/path/to/whatever/is/appropriate

no idea what this would take, apologies in advance if it's one of these 😅

Hi, first, thanks for this package!

I have a request - I am sometimes working on a local branch (not pushed to a remote location) and in this case using git-link generate a wrong url. Would it be possible to allow to chose the branch in some cases? I am thinking of something simple, e.g:

M-x git-link => do not prompt, generate link
C-u M-x git-link => ask for the remote name first
C-u C-u M-x git-link => ask for the remote and the branch name

Note that the first two options are already working this way, so it should not break the workflow for other users.

What do you think? I could work on a simple PR to implement this if you like the idea.

BitBucket now supports this. 🎉

There's currently no way to get the link for use in other elisp functions. It'd be nice if the commands returned the link in addition to writing it to the Messages buffer.

I've got a one link fix and I'll submit a pull request.

Emacs 26.1:

In end of data:
git-link.el:495:1:Warning: the following functions are not known to be
    defined: dired-file-name-at-point, magit-file-at-point, string-blank-p
emacs -Q --batch -L . -l ert -l git-link-test.el -f ert-run-tests-batch-and-exit
Args out of range: "", 1, nil

Changelog for Emacs > 25.1:

* lisp/url/url-parse.el (url-path-and-query): Do not artificially turn empty
path and query into nil path and query, respectively.

Dissecting empty path now returns "" instead of nil.

It would seem advisable to add more recent Emacs releases to the Travis test matrix?
Also the emacs-snapshot used is also outdated:

Setting environment variables from .travis.yml
$ export EMACS=emacs-snapshot
...
0.01s$ emacs --version
GNU Emacs 24.3.1

Hi, I updated the git-link package to the latest one and my custom function in "git-link-remote-alist" stopped working (produces incorrect URLs).

I've been using git-link for 3+ years without any issues with the config pasted below.

The issue is DIRNAME passed to my function is invalid. I've narrowed down the issue to git-link--parse-remote.

Here's how to reproduce it:

(git-link--parse-remote "[email protected]:dir")
;; returns ("my.company.internal" "/")
;; expected ("my.company.internal" "dir")

This is the git config:

$ git config --get remote.origin.url
[email protected]:dir/

Could you please review the parsing in git-link--parse-remote? I suspect it has changed. I haven't binary-searched for the breaking commit, but it should be committed the last 1-2 years. Sorry, I don't know what was the previous version which was working for me. EDIT: last working version is in the comment below.

Thanks for this package, it has been one of my daily tools!

Config ("XXX" obfuscates what I don't want to share):

(use-package git-link
  :ensure t
  :config
  (add-to-list 'git-link-remote-alist '("XXX" git-link-xxx))

  (defun git-link-xxx (hostname dirname filename branch commit start end)
    (format "XXX/%s/%s@%s/-/blob/%s"
            hostname
            dirname
            (or branch commit)
            (concat filename
                    (when start
                      (concat "#"
                              (if end
                                  (format "L%s-%s" start end)
                                (format "L%s" start))))))))

In case there is a trailing slash at the end of the remote url (https://git.savannah.gnu.org/git/guix.git/), the link generated by git-link will look like:

https://git.savannah.gnu.org/cgit/guix.git/.git/tree/TODO?h=587fbb48be8ee0c76c77f14fd835e79f33752cb1#n76

instead of:
https://git.savannah.gnu.org/cgit/guix.git/tree/TODO?h=587fbb48be8ee0c76c77f14fd835e79f33752cb1#n76

Using https://git.savannah.gnu.org/git/guix.git solves the problem.

Not a big deal, just to let you and maybe other people know.

At my company we host our git repositories on gitlab and access them through port 2222.
For example, the url config on one of our repositories is:
url = ssh://[email protected]:2222/tools/ImsHealth.Automation.git

The function git-link--remote-host fails when there is a port, simply returning "2222".

https://github.com/sshaw/git-link/blob/master/git-link.el#L163

It should return "gitlab.imshealth.com".

hi! first off, thanks again for git-link. it's great!

i recently upgraded to 0.5.1 (not sure of the older version i was on, sorry), and i now get the error message Result: "No handler for USERNAME" in repos where the first remote URL is http with username and token, e.g. https://snarfed:[email protected]/snarfed/foo.git. i think these URLs worked in the earlier version i upgraded from.

remote URLs with git: or https: without username/token still work fine.

thanks in advance!

While trying to setup git-link for a cgit-powered repository (https://git.adrian.geek.nz/rhapsode.git), it wouldn't work, because https://github.com/sshaw/git-link/blob/master/git-link.el#L412-L414 strips ".git" from the directory name. As a workaround, I currently do something similar to git-link-savannah where I pass a modified dirname variable.

A repo whose origin is something like https://git.savannah.gnu.org/git/emacs.git is can be viewed at https://git.savannah.gnu.org/cgit/emacs.git (note the additional 'c').

git-link gives an invalid url when the branch name has a # in it. #2-fix-some-issue for example. The hash will need to be escaped to %23 to get valid URLs.

For the permalink preview to appear I think the capitalization must be matched exactly.

https://github.com/Sshaw/git-link/blob/efd14ab5f17f5942d25e165210447f3983f3250e/git-link-test.el#L6

It seems git-link produces lower-case permalinks in all cases. I don't know how involved this fix is for such a tiny issue, nor if the properly capitalized string is even available.

I get a ton of value out of git-link -- thank you for the terrific package!

Currently when looking at a file associated with a commit (buffer-file-name) returns nil so we cannot generate the link. Steps should be taken to get the info necessary to generate it from magit -or something.

Given a git repository contained in the folder foo, if (from this folder) the command git worktree add ../foo-worktree-otherbranch otherbranch is executed, a worktree will be created for the otherbranch branch in the folder ../foo-worktree-otherbranch (relative to the foo folder).

When editing a file within the foo-worktree-otherbranch folder, and attempting to use git-link, the error Remote 'origin' not found occurs. Instead, git-link should be able to correctly identify the remote and branch. In the particular case this was tested under, the foo repository didn't even have an origin remote (but did have other remotes).

I sometimes want to share the branch name when I share a file. Most of the link functions seem to ignore the branch name, perhaps you could have a defvar to control whether to link to the branch or the commit.

If one changes this (M-x cd) to a directory that's not a git repository then the link cannot be generated.

Whenever using git-link on these files for GitHub/Bitbucket I usually have to use the blame/annotate url to link vs GitLab does the what I would expect.

https://gitlab.com/protesilaos/modus-themes/-/blob/main/README.md#L1-13 vs https://gitlab.com/protesilaos/modus-themes/-/blob/main/README.md

vs

https://github.com/sshaw/git-link/blob/master/README.md#L6-L11 (does nothing, other than open the link) vs https://github.com/sshaw/git-link/blame/master/README.md#L6-L11 links to and highlights lines 6-11.

vs

https://bitbucket.org/tutorials/markdowndemo/src/master/README.md?at=master#README.md-1:11 (does nothing, other than open the link) vs https://bitbucket.org/tutorials/markdowndemo/annotate/master/README.md?at=master#README.md-1:11

If I was wanting to add this feature where would be the best place to add this?