It'll instantly expand the URL to its canonical form, e.g.
which stays valid indefinitely (unless the commit is deleted from the repo).
P.S. Hit the ? key for more keyboard awesomeness. :)
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 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"
When I send someone a link, it's because I want them to see what I'm looking at.
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.
(Full disclosure: I'm one of the creators of 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.)
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)
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.
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.
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...
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.
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.
'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.
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).
An accurate title would look more like "Use commit-specific links when linking to line numbers on Github".
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.