Don't link to line numbers in GitHub(andrew.yurisich.com)
andrew.yurisich.com
Don't link to line numbers in GitHub
http://andrew.yurisich.com/work/2014/07/16/dont-link-that-line-number/
59 comments
This is huge.
Yeah, that's what he said in the post.
Not what he said in the title though. Should be "don't link to non-canonical urls on github", line numbers are irrelevant.
We're meant to read more than the title nowadays?
Like the original comment, my original thought was that it was probably something to do with people referring to line numbers on HEAD. A less link-bait title that confirmed this would have allowed me to easily skip this this article which, for my purposes, was useless.
This seems glaringly obvious.
If you statically link to a specific line number, and if your source code changes, then your static link may not point to the same code... duh?
If you statically link to a specific line number, and if your source code changes, then your static link may not point to the same code... duh?
I actually feel that the post isn't even just about people who don't know that linking to a line number in a changing file will result in incorrect information later. I think it's more that when people link to code, they think it doesn't matter, so it's not something they actively care about. So they don't take the extra time to link to the actual commit since it's not a thing they care about.
I feel the authors real value in their article is a call for people to care about correcting their links for programmers in the future. The article would be better served to say, "Why you should care about linking in time to your GIT repo"
I feel the authors real value in their article is a call for people to care about correcting their links for programmers in the future. The article would be better served to say, "Why you should care about linking in time to your GIT repo"
Thanks! It was a pain. Especially if you've moved from Bitbucket where "stable" links to line numbers are default.
Another reason to love github, thanks.
Why doesn't the URL look how it would look if you hit y by default? Seems like that would be what you usually want.
When I send someone a link, it's because I want them to see what I'm looking at.
When I send someone a link, it's because I want them to see what I'm looking at.
When I paste a link from A (which I control) into B (which I control) , I want to be able to change A and have people who click on the link from B get the new A, not the old A. It's the same reason you ideally want to specify depedencies by branch, not by tag.
"Don't Link that Line Number!" -> "Don't use unstable references if you need stable ones"
Yea, unnecessarily controversial title. The point is that if you want to link to some code, link to a particular version of that code, not the latest version of that code. The whole file could be deleted, let alone a change in line position.
I'm going to play the advocate of the devil here, and say that it's a necessary controversial title. HN is so crowded these days that an uncontroversial title would never have gotten enough upvotes within 10 minutes to get on the front page.
I would also say "necessary" controversial title, but because as a relative newbie to GitHub I might have made this mistake without thinking about it. Now I know, whereas before I didn't; and if the title wasn't engaging/controversial enough for me to click on it, I wouldn't.
I would've gone with "Billy, Billy don't you lose my number". :)
Did it need to be on the front page?
I had the same realization a while ago, even started working on a documentation engine built around the idea that I never quite finished:
https://github.com/32bitkid/zang
The general concept was a markdown preprocessor that would include references to commits in git repositories and expand to the referenced content.
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.
it would generate a warning/error and one would have to update the documentation accordingly.
Anyway nice to see other people with the same underlying idea.
https://github.com/32bitkid/zang
The general concept was a markdown preprocessor that would include references to commits in git repositories and expand to the referenced content.
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.
it would generate a warning/error and one would have to update the documentation accordingly.
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.
Like https://sourcegraph.com/code.google.com/p/go/.GoPackage/net/....
(Full disclosure: I'm one of the creators of Sourcegraph.)
Like https://sourcegraph.com/code.google.com/p/go/.GoPackage/net/....
(Full disclosure: I'm one of the creators of Sourcegraph.)
I really begin to like sourcegraph, nice job! I don't know how to ask the question without sounding too negative: any chance it might get faster? I took about 10 seconds (just a feeling, didn't measure it) to load the page.
Not too negative. We love hearing from people who use Sourcegraph. :)
Which page was it, and does it take that long every time you load that page?
We have improved average page load time a lot (it's now 200-500msec), but we're seeing a lot of variance on pages with a lot of data and when DB load spikes during backend build imports. So, just know we are working on it, and let us know about specific things that are really slow. (We track all page load timings, but we try to prioritize what matters to our users most.)
Which page was it, and does it take that long every time you load that page?
We have improved average page load time a lot (it's now 200-500msec), but we're seeing a lot of variance on pages with a lot of data and when DB load spikes during backend build imports. So, just know we are working on it, and let us know about specific things that are really slow. (We track all page load timings, but we try to prioritize what matters to our users most.)
It was the page you've linked to (https://sourcegraph.com/code.google.com/p/go/.GoPackage/net/...)
just now about 7 seconds (repeatable), on a faster machine it went down to 3 seconds (also repeatable) (all numbers are from me counting in my head, so this is not exact)
just now about 7 seconds (repeatable), on a faster machine it went down to 3 seconds (also repeatable) (all numbers are from me counting in my head, so this is not exact)
Hmm, interesting. I'll follow up with you by email. Thanks for reporting this.
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's great.
https://github.com/ehamiter/ST2-GitHubinator
https://github.com/ehamiter/ST2-GitHubinator
> Then, tap the "y" key to jump to the last commit found for that region.
That's not actually what happens. Pressing "y" resolves the current reference (master, some tag, whatever). It has nothing to do with what you select, you're just following the pointer that is the current ref.
That's not actually what happens. Pressing "y" resolves the current reference (master, some tag, whatever). It has nothing to do with what you select, you'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't need to avoid line numbers, you just need to link to a specific commit.
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.
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.
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.
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/tag on github? If not, it might be good UX to remove that option. i.e. only honour such links to immutable urls.
Further, even if you're looking at a mutable reference (like master), the line number links could/should be to the underlying immutable url (based on the commit).
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...
Further, even if you're looking at a mutable reference (like master), the line number links could/should be to the underlying immutable url (based on the commit).
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...
Linking to line numbers is practically using goto, which is a coding faux pas. I'm sure they must be on the way out.
Yes, in a team working remotely it is often useful to link to a specific chunk of code during a (voice or chat) conversation. Typically you're talking about the current code in a branch, and it is useful for the person clicking the link to know that we are in fact talking about HEAD and not a specific commit.
This is the equivalent of calling someone to your desk and pointing at the screen. It is fine if those links stop working a few hours later.
This is the equivalent of calling someone to your desk and pointing at the screen. It is fine if those links stop working a few hours later.
I think that also works if the link is actually to the immutable commit to which the branch is currently pointing?
Good point, it would make sense to disable the feature for mutable references like "master".
This works great unless you'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't expect changes earlier in the file I'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.
You already know the answer to that problem: «Do not rebase commits that you have pushed to a public repository.» - - [http://git-scm.com/book/en/Git-Branching-Rebasing]
Trite one-liners aside, I think you'll find in practice that some good teams rebase commits on feature branches all the time in order to keep the commit history readable. The implicit contract in that case is that nobody else considers that branch to be usable until it's merged.
It all comes down to the definition of publicity. If your team considers a feature branch to be privately owned by the requestor except for the purposes of code review, it works great.
It all comes down to the definition of publicity. If your team considers a feature branch to be privately owned by the requestor except for the purposes of code review, it works great.
I do not mind feature branch rebasing, when it does not violate the publicity rule (let's call it that). After the history is public, rewriting history is such a dangerous endeavor as to be completely inadvisable. More so, if one is actually looking at the end goal: a linear repository history. I can't even understand the need for a (fake) linear repository history.
I have come to understand the need.
If a feature branch is under development for a year, and then merged in.... you wind up with commits in master that only appeared today, but are dated (and appear in the commit history timeline) up to a year ago. It's actually a different kind of 'rewriting history', really.
This can be very confusing when trying to figure out what happened. And even worse when trying to figure out where a bug was introduced (via git bisect or manually).
Still, I, like you, try to avoid rebase history rewrites whenever possible, because they can lead to such messes. But I've come to understand why people want them, it's not just "aesthetically pleasing commit history", which sounds kind of inane I agree.
Then "only when it's not public" rule effectively means "never do it" for most people's development practices. Anything that takes longer than an hour or so for me to do is going to be in a public repo, for the 'backup' nature of making sure i don't lose it while in progress if nothing else. Anything that more than one person collaborates on (or you want code review suggestions on) obviously is going to be in a public repo. It's pretty rare feature branch work I do that never makes it into a public repo (before it's committed to master).
If a feature branch is under development for a year, and then merged in.... you wind up with commits in master that only appeared today, but are dated (and appear in the commit history timeline) up to a year ago. It's actually a different kind of 'rewriting history', really.
This can be very confusing when trying to figure out what happened. And even worse when trying to figure out where a bug was introduced (via git bisect or manually).
Still, I, like you, try to avoid rebase history rewrites whenever possible, because they can lead to such messes. But I've come to understand why people want them, it's not just "aesthetically pleasing commit history", which sounds kind of inane I agree.
Then "only when it's not public" rule effectively means "never do it" for most people's development practices. Anything that takes longer than an hour or so for me to do is going to be in a public repo, for the 'backup' nature of making sure i don't lose it while in progress if nothing else. Anything that more than one person collaborates on (or you want code review suggestions on) obviously is going to be in a public repo. It's pretty rare feature branch work I do that never makes it into a public repo (before it's committed to master).
> The implicit contract in that case is that nobody else considers that branch to be usable until it's merged.
'not usable', then, includes not being able to link to specific sourcecode in that branch with a URL.
You pays your money and you takes your chance.
'not usable', then, includes not being able to link to specific sourcecode in that branch with a URL.
You pays your money and you takes your chance.
I often wished that I could link to function names or so instead.
In Trac you can link to #/searchterm.
I've always linked to line numbers under specific commits or tags. Didn't know about the 'y' shortcut though, very helpful.
That'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'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.
Please don't mention that you flagged the OP. That's against the guidelines: If you flag something, please don't also comment that you did.
Short but informative
Someone just discovered space-time
Why change the title to "Don't link to line numbers in GitHub", when that's not what the article is saying at all?
The original title is "Don't Link that Line Number" which also isn't what the article is saying, so the HN re-title is an improvement.
An accurate title would look more like "Use commit-specific links when linking to line numbers on Github".
An accurate title would look more like "Use commit-specific links when linking to line numbers on Github".
The original title (as written in the article), is actually "Don't Link That Line Number!" Even without the exclamation though, I think that clueful readers would know that this choice of title is a stylistic one.
Title choice is largely a matter of style. So, I guess I'm wondering why any of them need to be changed?
Furthermore, it seems to be completely arbitrary. The techcrunch article titled "#Love: Virtually No Sex" if made accurate would have been "People may be losing interest in sex". The "Simpler and faster GC for Go" would have been "Proposal for Simpler and faster GC for Go". Etc.
Title choice is largely a matter of style. So, I guess I'm wondering why any of them need to be changed?
Furthermore, it seems to be completely arbitrary. The techcrunch article titled "#Love: Virtually No Sex" if made accurate would have been "People may be losing interest in sex". The "Simpler and faster GC for Go" would have been "Proposal for Simpler and faster GC for Go". Etc.
I agree. I misinterpreted your initial comment.
Why would you assume that a link is good for more than 1 day ?
Because the whole infrastructure of the web depends on it. Including Google's $380 billion market cap.
It'll instantly expand the URL to its canonical form, e.g.
https://github.com/sass/libsass/blob/master/parser.cpp#L29-L...
to
https://github.com/sass/libsass/blob/fca1f75a14fe5336c7b1a4b...
which stays valid indefinitely (unless the commit is deleted from the repo).
P.S. Hit the ? key for more keyboard awesomeness. :)