Support branch relative links in on root of repo #84

doapp-ryanp opened this Issue Oct 12, 2011 · 80 comments


None yet

Relative html anchor links work great from one .md file to another, however they do not work from the if it is in the root of the repo. By default, github renders the file in the webapp, and all relative links in there are relative to the URL (which does not include any branch name). It would be sweet if you added logic to this special case to create anchors so they included the current branch.

I have written up a detailed explanation of the problem and an example here:

I would like this as well so I can write documentation that references the code.

mloskot commented Dec 19, 2011

I've been just looking for similar feature, trying to use SHA or branch or repo links in my
It would be a sweet feature.

cbeams commented Dec 20, 2011

+1. relative links from a concise file to, let's say, a more detailed allows for keeping such documentation in sync with the code instead of relying on the wiki.


technoweenie commented Dec 20, 2011

We tried adding a <base> tag for this, but it causes problems with other relative links on the site.

@technoweenie any other comments? This was a feature request / not a bug. Github already sports its own "Github Flavored Markdown", and since github has special relative paths - it makes sense to make these work in the github sense.

Or, are you saying, "No, we will not entertain this feature request"? And basically, we're only talking about the here- which is also specific to github in that it displays the read me as the project index.

bpierre commented Jan 20, 2012

Is there any chance you reopen this issue?

Why not rewrite the relative URLs in .md files with the absolute ones (only for the HTML rendering)?

There are also some other creative options. Could use iframe for the preview of the .md, and relative links would work. You could also potentially leverage the HTML base tag ( ). Could write some JS code that identifies links in the .md preview and alters based on the current/default branch.

@technoweenie Can't you please try again? There is always some solution. This request is a very important one because without it, the whole process of "pull requests" gets really messy when it comes to documentation. URLs for snapshots etc. have to be rewritten and there is no way to do a clean merge out of the pull request. Please reconsider & try a different approach.

dblock commented Feb 20, 2012

+1, this is super painful for open-sourcing wiki-like content


technoweenie commented Feb 21, 2012

The problem is readmes can be viewed on multiple URLs. Every solution requires a pile of hacks:

  • Keep multiple caches of the rendered readme to work on every page it's displayed.
  • iframe/javascript whammy jammy.

One solution works great: use absolute URLs. Don't assume your README will always be read on GitHub.

Hit up if you want to talk about GitHub issues. This is out of scope of this small OSS library.

dblock commented Feb 21, 2012

@technoweenie I feel your pain, but maybe you could fix the 75% scenario?

Each markdown file is truly located in one place, the real URL is something like - so why not add a substitution like link - every ./ would be replaced by the real location of the file?

Sorry if I keep discussing the issue here, already hit support. Wil stop now.


Don't assume your README will always be read on GitHub.

That's exactly what I'd like to avoid - hard-coding absolute links to the GitHub website instead of using relative ones to link to files in the same directory. That way if you're reading it outside GitHub you get a link to the local copy of the file.

I'll email that same thing to as you said.


odalet commented Feb 25, 2012

It's all the more a hassle as relative links work when clicked from an explicitly opened

completely agree with odalet, but that made me think...
maybe all that should be done is to make the READ MORE link not to point to the #readme anymore but to,
Would that not solve the problem?


@sol sol added a commit to sol/gentoo-haskell that referenced this issue Apr 8, 2012

@sol sol Fix broken link in README
I first tried to use some relative URL, but this does not work reliable
(see github/markup#84).

@FichteFoll FichteFoll added a commit to FichteFoll/InsertDate that referenced this issue May 13, 2012

@FichteFoll FichteFoll Fix broken relative links ece2ff2

breerly commented May 31, 2012

+1 - no go?

Can we get some kind of feature to alleviate this pain? Even if its a repository setting, a callback script, or something we can set somewhere that will allow us to rewrite certain links depending on the branch that README/doc is in? Something, anything, throw us a bone here, please!



especially also important for relative image links!!


danmunn commented Jun 21, 2012


0xced commented Jul 1, 2012



relative links should work seamlessly, that would allow generated docs to use the same links as github

lorrin commented Aug 15, 2012

I would appreciate working relative links too, though I agree a GitHub based feature outside of the library might make the most sense.

est commented Aug 29, 2012

github should just put wiki under the project directory like Google Code. Then you can link what you want.


Thanks for the new feature "Contributing Guidelines"!

However, when trying to link from the to the new I ran into this relative link issue. Would be great if this could be fixed :) Thanks!

I agree with my predecessors that this is a major pain point for writing decent docs that do not end up being a 1000-line

Another use case @davejamesmiller already touched as well: When in my repo I have /docs/**/*.md and want to link against those from each other, I have to pass in a full Github url. This has two major drawbacks:

  1. When I generate API docs for (in my case) ruby projects using yard, the supplementary docs will not be linked properly. This leads to invalid linking on services like as well as locally generated documentation, forcing developers to either hardcode links to github even for local docs, or breaking relative links on Github
  2. When using hardcoded links to the github rendering of the projects, the documentation is always coming from the branch linked against. This leads to many problems when browsing older docs, either on github or in local/online API docs: The links will point users to documentation that does not apply to the version of the library they are using. Say the rails project was using this documentation strategy: If they linked to docs/ as a hard-coded link to github/master and a user still stuck on 2.3 would browse the API docs for his version, either on the Github branch or locally or wherever, clicking such a link will kick him to the latest version that applies to the soon-to-come 4.0 release, and even more so probably without realizing this. A real-world example of this problem is the Resque library: The documentation of the 2-year-old version 1.8.0 points developers to the most up-to-date version of docs/ instead of the one on the 1.18.0 tag

If you guys found a way to fix this, documentation for any given point in time would remain consistent when browsing the docs on github as well as anywhere else, and that would be greatly appreciated!

bump. Please give us a feature that will alleviate this pain.

b-long commented Sep 19, 2012


TylerBrock referenced this issue in mongodb/mongo-ruby-driver Sep 21, 2012


Fix links #115

Using absolute URL's is definitely not a solution because it doesn't support branches / tags (URL's would always point to master, right?). Also, like @davejamesmiller and even @technoweenie mentioned, Markdown files are not viewed only in GitHub, so relative paths are important and again absolute URL's are not the solution.

Not to be a dick, but I'd say this is not an enhancement, but a bug really.

six8 commented Oct 10, 2012


The whole problem arises because in a path like "master" is treated as a filename, not a directory. If a trailing slash was enforced (ex: ```) as is the standard then relative URLs would work perfectly.

colszowka referenced this issue in colszowka/simplecov Oct 10, 2012


Re-structure documentation #170

Indeed - adding that trailing slash to the URL fixes it - but that seems like a github infra issue, not related to this library?

six8 commented Oct 18, 2012

It is a github infrastructure issue but also an issue for anyone else setting up a simular infrastructure.

@technoweenie Based on your comments, note that having only absolute paths makes reading the file everywhere worst, for example you cannot follow links locally, and the absolute links will point to a specific version.

I don't know the implications of the solution, but even when I don't know the github UI code internals, a solution based in JavaScript is not ugly as you describe it:

  • The change will be only in one place the README presentation logic, it doesn't affect the markup parsing.
  • In the browser is very easy to search for all a/img tags inside the README container, check if the href is relative and make it absolute based on the current branch

Maybe this kind of solution doesn't cover all the possible use cases, and maybe the reason to close it is because the functionality clashes a little bit with the Wiki stuff. But a lot of users like me wants it... please listen to your users, and consider to reopen it.

Maybe you can find an alternative solution that covers the user goals, in my case that is to have a starting point for the documentation that goes with the source code. The wiki doesn't work for me, because I want to keep the Markdown files inside a docs folder of the source tree, and since the first thing that the devs see in GitHub is the README its the ideal place to place documentation pointers.

elijh commented Oct 28, 2012


danfuzz commented Oct 29, 2012


Thanks in advance for your re-consideration!

Mikolaj commented Oct 30, 2012


@Mikolaj Mikolaj added a commit to Mikolaj/haskell-linux-perf that referenced this issue Oct 30, 2012

@Mikolaj Mikolaj Convert the docs to markdown
Links between the files still do not work due to github/markup#84.

joeyespo commented Nov 7, 2012


mnapoli commented Nov 14, 2012


+1 to everyone else, would really help !

clakech commented Dec 6, 2012


For you information, if you watch a using this kind of url ( with a slash at the end instead of ( without slash at then end... then relative link works!


ardumont commented Dec 6, 2012



denlab commented Dec 7, 2012


massyl commented Dec 7, 2012


technoweenie: One solution works great: use absolute URLs.

@technoweenie The keyword that I've always heard with git is distributed. Using absolute URLs seems to go against the idea of distributed and more towards centralized.

@technoweenie you do not follow the git branches with absolute url too.

On Fri, Dec 7, 2012 at 8:35 PM, Jacob Berger notifications@github.comwrote:

technoweenie: One solution works great: use absolute URLs.

@technoweenie The keyword that I've
always heard with git is distributed. Using absolute URLs seems to go
against the idea of distributed and more towards centralized.

Reply to this email directly or view it on GitHub

I was looking around the code in this repo recently. I think @technoweenie and others are right, there's not much this code can do to help. This library merely forwards the 'render' calls to the respective libraries. And in Markdown, for example, the relative URLs are just translated directly to <a> or <img> elements.

I'm really looking forward to a fix, but it'll either be a fix in internal GitHub code, or by adding a post-processor here that resolve all relative URLs in <a> and <img> elements to absolute ones, happening after the call to render. The post-processor would take an absolute URL like the one used in <base> a while back.

@joeyespo I dug into the code as well and your findings are correct.

This is a great issue, just in the wrong place.

@bergerjac well, I am unsure there is a place where this issue can be filed against private github code, so this is the only place we can have a public discussion on the matter. Does GH have an issue tracker for things like this?

Agreed, @ralphschindler. +1

If this isn't the right place, don't just pretend there isn't a problem. Move the issue to the right place instead.


And I wish it work not only for markdown, but for other markup formats supported by github, like .org


@csabapalfi csabapalfi added a commit to csabapalfi/algorithm-design-manual that referenced this issue Dec 28, 2012

@csabapalfi csabapalfi absolute links because of github/markup#84 and github/markup#101 641136c

dhladky commented Jan 4, 2013


This issue is closed, but there is a opened duplicate - #101

Makes sense to post your +1's there.


awesome, thanks for all the push on this guys and to github for implementing.

Great! Thanks to all involved!

dhladky commented Feb 4, 2013

Hmmm, if I understand the blog well, one needs to keep the names of md files unique. That is far from optimal. If you had serveral files in each directory, you still can not link them.

@dhladky How exactly do you intend to have multiple files of the same name in the same directory on your filesystem?

dhladky commented Feb 4, 2013

I was not precise. Imagine a directory tree, where each folder has one file. It is entirely possible. However the way you can create the relative link according to the blog is just the "" (no path). Which of the files do you refer if you do so? The way described in the blog means you have to have the file names to be unique no matter where in the directory tree they are. If you have a large project and you have some naming convention you are done.

I see. Actually I think the blog post example is somewhat badly picked as it only refers to items at the root level. Something like [other readme](docs/foo/bar/baz/ should work as expected relative to the current branch root, so in this case it should link to the path docs/foo/bar/baz/

dhladky commented Feb 4, 2013

What I understand in the blog, if you had docs/foo/bar/baz/ you need to change it to just I will investigate how it works. If docs/foo/bar/baz/ worked and the link was calculated to match the proper branch, it would be brilliant.

From what I reckon that was the purpose of this whole excercise :)

dhladky commented Feb 4, 2013

It was and that is why I was disappointed after reading the blog. :)

swmcc referenced this issue in sevenweeks/databases May 25, 2013


Fix relative links #3

@thlorenz thlorenz added a commit to thlorenz/node-browserify that referenced this issue Jan 21, 2014

@thlorenz thlorenz adding browserify tools wiki link
- all tools that were there are now in that wiki, so I removed them from that section
- fixed list of transforms wiki link (relative links not working: github/markup#84)

thlorenz referenced this issue in substack/node-browserify Jan 21, 2014


adding browserify tools wiki link #602

@substack substack added a commit to substack/node-browserify that referenced this issue Jan 22, 2014

@thlorenz @substack thlorenz + substack adding browserify tools wiki link
- all tools that were there are now in that wiki, so I removed them from that section
- fixed list of transforms wiki link (relative links not working: github/markup#84)

@psibre psibre added a commit to marytts/marytts-txt2wav that referenced this issue May 27, 2015

@psibre psibre fix relative link to branch 23fe233

+1 to variables support (branch, etc)

muescha commented Sep 18, 2015


it should use relative links in issues/pullrequests/comments in pull requests



i write something in a comment of a pull request


i would like to write [options](website/documentation/


it matches to:


it should be matched to this:

Any news about this?

@timofonic news about what? This feature is implemented long ago.

muescha commented Dec 2, 2015

@avodonosov in pull requests its still not implemented

@muescha @tiabobia ah, pull requests. Probably discussing it in a closed issue might be inefficient. Also, have you seen #285 ?

muescha commented Dec 7, 2015

@avodonosov ok i will open a new issue for this

here is the number: #576

Did this ever get fixed/implemented?

+1 to variables support (username/repo) as CI build plaques/links are a source of pain in forked repos

This idea lives again in #913!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment