Don't link to line numbers in GitHub

ProTip: Hit the <i></i>y<i></i> key on any GitHub page with source code.<p>It&#x27;ll instantly expand the URL to its canonical form, e.g.<p><a href="https://github.com/sass/libsass/blob/master/parser.cpp#L29-L36" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;sass&#x2F;libsass&#x2F;blob&#x2F;master&#x2F;parser.cpp#L29-L...</a><p>to<p><a href="https://github.com/sass/libsass/blob/fca1f75a14fe5336c7b1a4b38c69bda7fece714f/parser.cpp#L29-L36" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;sass&#x2F;libsass&#x2F;blob&#x2F;fca1f75a14fe5336c7b1a4b...</a><p>which stays valid indefinitely (unless the commit is deleted from the repo).<p>P.S. Hit the <i></i>?<i></i> key for more keyboard awesomeness. :)

&quot;Don&#x27;t Link that Line Number!&quot; -&gt; &quot;Don&#x27;t use unstable references if you need stable ones&quot;

I had the same realization a while ago, even started working on a documentation engine built around the idea that I never quite finished:<p><a href="https://github.com/32bitkid/zang" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;32bitkid&#x2F;zang</a><p>The general concept was a markdown preprocessor that would include references to commits in git repositories and expand to the referenced content.<p>Because all the references were bound to a commit, then a) they were stable (if you used a hash rather than brach name), but more importantly b) you could determine when the file had changed and the documentation was possibly out of date.<p>it would generate a warning&#x2F;error and one would have to update the documentation accordingly.<p>Anyway nice to see other people with the same underlying idea.

Or link directly to functions on Sourcegraph, if you are referring to a function and not just a line range.<p>Like <a href="https://sourcegraph.com/code.google.com/p/go/.GoPackage/net/http/.def/Get" rel="nofollow">https:&#x2F;&#x2F;sourcegraph.com&#x2F;code.google.com&#x2F;p&#x2F;go&#x2F;.GoPackage&#x2F;net&#x2F;...</a>.<p>(Full disclosure: I&#x27;m one of the creators of Sourcegraph.)

I totally agree. The problem is not links to line numbers, that I found really useful, the problem is that these links must have a commit context otherwise they become unreliable.

If you use Sublime Text the Githubinator plugin provides shortcuts to create a permalink to GitHub for the current selection in your editor. I use it all the time - it&#x27;s great.<p><a href="https://github.com/ehamiter/ST2-GitHubinator" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ehamiter&#x2F;ST2-GitHubinator</a>

&gt; Then, tap the &quot;y&quot; key to jump to the last commit found for that region.<p>That&#x27;s not actually what happens. Pressing &quot;y&quot; resolves the current reference (master, some tag, whatever). It has nothing to do with what you select, you&#x27;re just following the pointer that is the current ref.

You can of course link to a line number on a specific commit. You don&#x27;t need to avoid line numbers, you just need to link to a specific commit.<p>The y shortcut is super helpful though -- I was always trying to figure out how to get the the latest commit hash on my own before, clicking on the latest commit in history etc., very cumbersome.<p>This is important enough for linking to sourcecode (I agree), that I kind of wish github had an actual button for it on screen, instead of having to know the magic shortcut. But I realize github screen real estate is precious.

Is there a reasonable use case for linking to line-numbers on branch&#x2F;tag on github? If not, it might be good UX to remove that option. i.e. only honour such links to immutable urls.<p>Further, even if you&#x27;re looking at a mutable reference (like master), the line number links could&#x2F;should be to the underlying immutable url (based on the commit).<p>If there is a marginal use case for linking to line numbers of mutable refs, perhaps it should be the non-default case, discoverable by keyboard shortcut like this...

This works great unless you&#x27;re rebasing and the commit hash you reference falls out of use. In PR comments that I expect to rebase again before release but for which I don&#x27;t expect changes earlier in the file I&#x27;m referencing, I often live on the edge and link to the mutable diff. In the context of PR comments, you can edit them after the fact, so neither choice is necessarily game over - you can fix the line number or the commit hash you point to after the fact.

I often wished that I could link to function names or so instead.

I&#x27;ve always linked to line numbers under specific commits or tags. Didn&#x27;t know about the &#x27;y&#x27; shortcut though, very helpful.

That&#x27;s easy to fix- link to a line in a specific commit. Assuming you never clobber the history, that link should remain constant.

Anyone with minimal knowledge of github would know that the references can changes...

This has nothing to do with line numbers whatsoever, it&#x27;s about constructing links using whatever commit the branch is currently on rather than linking to the branch. A regular link to a file using a branch reference could just as easily disappear completely as the branch reference moves.

Short but informative

Someone just discovered space-time

Why change the title to &quot;Don&#x27;t link to line numbers in GitHub&quot;, when that&#x27;s not what the article is saying at all?

Why would you assume that a link is good for more than 1 day ?

Is it not possible to link to line numbers in that commit? I know you can link to specific files in the commits