How to link to other repos in readme.md files

[jezmck]

I’d like to link to (e.g.) https://github.com/vuejs/vue in my personal readme, but it feels wrong to have to include the https://github.com/ part.

Is there no way to have a link relative to the whole github site?

[yamiacat]

Hi @jezmck!

I’m afraid we don’t support relative links across the site, no, sorry!

You can always use conventional markdown syntax to create links that are easier on the eye, though?

For example:

[Vue](https://github.com/vuejs/vue)

…is rendered as Vue

Does that help?

[jezmck]

Okay. How do I turn this into a feature request?

[yamiacat]

You can submit a feature request through our official product feedback form so that our product team can see exactly how you’d like GitHub to work!

[Dayan94]

I also want the same feature to be included in GitHub. Four years have passed and no change in the markdown file full URL writing in the same account's different repositories' readme files.

[jimmy-zhening-luo]

@jezmck, was this ever submitted as a feature request? I'm curious why GitHub can autolink humans like @jimmy-zhening-luo; organizations like @w3c; and issues, PRs, and even commits (by SHA!) inside of repos — but not the root of those same repos?

These take me where I want to go ✅

• Options in a Worksheet jlord/sheetsee.js#26 repo -> issue
• @jlord user root
• @community org root

But these do not ❌

1. @community/community repo root
2. community/community repo root
3. jlord/sheetsee.js# repo root
4. jlord/sheetsee.js@ repo root

Proposal

Of the negative example syntaxes, only (3) or (4) or some variation thereof seems like reasonable candidates.

• (1) is already reserved for tagging a team inside an organization
• (2) would false positive far too often

On the other hand, (3) and (4) could reasonably autolink IMO if the following are fulfilled:

• Standalone token (e.g. not part of URL or email address)
• When using #, possibly require another trigger word like foo/bar#README¹ to take you to the root, or a second hash like foo/bar##.
• When using @, to avoid conflation with commits, IMO it is safest simply to require an empth @, e.g. foo/bar@. (For all you Microsofties, did you know that this is how Google engineers write aliases, which they call LDAPs? Everything really is opposite there.)
• Both cases maximally avoid symbol/namespace conflicts because the trigger tokens reside at the end of resolvable syntaxes.
• Both cases mitigate false positives with other @ and # bounded items by requiring the link to be a standalone (bounded) token. GitHub also checks if the URL is resolvable as a precondition for rendering an autolink. Combined, this seems at least as safe from FPs as the existing autolinks supported by GitHub.

Footnotes

1. N.B. The # syntax also makes relative linking possible which is what @Dayan94 requested, but I will note that what @jezmck requested was not relative linking, since they were simply asking to be able to reference a repo's root. Ironically, GitHub actually does support relative auto-linking like the aforementioned Options in a Worksheet jlord/sheetsee.js#26, and relative non-auto-linking like vuejs/vue [vuejs/vue](./../../../vuejs/vue) 😂. ↩

[jimmy-zhening-luo]

@yamiacat , I tried to open a feature request but the link you provided is dead, it just redirects to this same community discussion forum, in which there is no special Feature Request thread type that is distinct from this exsiting thread.