While I'm a little annoyed by this (it seemed unlikely to me that GitHub would shut it down, so I actually used it), I can live with it. The "was only lightly documented" comment is pretty unnecessary and just adds insult to injury though. What's that supposed to mean? It feels like such an "it's kinda your fault for putting too much faith in us" insinuation. GitHub literally blogged about the feature [1], did they expect people not to use it because it wasn't "heavily" documented? Should their users ignore their blogs from now on, because apparently it's an irresponsible thing to take their blogs at face value?<p>Oh, and I don't think they've sent anyone any notifications about this, like the repo owners. Not sure how people are supposed to find out; are all users expected to stay up to date with GitHub's blog... which GitHub is telling them not to trust?<p>[1] <a href="https://github.blog/2011-11-10-git-io-github-url-shortener/" rel="nofollow">https://github.blog/2011-11-10-git-io-github-url-shortener/</a>
<i>The problems with url shorteners</i> <a href="https://news.ycombinator.com/item?id=545565" rel="nofollow">https://news.ycombinator.com/item?id=545565</a> – 2009-04 (56 comments)<p><i>URL Shorteners – the herpes of the web</i> <a href="https://news.ycombinator.com/item?id=570041" rel="nofollow">https://news.ycombinator.com/item?id=570041</a> – 2009-04 (17 comments)<p><i>Url Shorteners: Destroying the Web Since 2002</i> <a href="https://news.ycombinator.com/item?id=660087" rel="nofollow">https://news.ycombinator.com/item?id=660087</a> – 2009-06 (57 comments)<p><i>URL Shorteners are evil, here's one to prove it.</i> <a href="https://news.ycombinator.com/item?id=904941" rel="nofollow">https://news.ycombinator.com/item?id=904941</a> – 2009-10 (57 comments) – ironically dead<p><i>Link shorteners hurt the user experience and destroy the Web</i> <a href="https://news.ycombinator.com/item?id=7803290" rel="nofollow">https://news.ycombinator.com/item?id=7803290</a> – 2014-05 (89 comments) – dead<p><i>The URL shortener situation is out of control</i> <a href="https://news.ycombinator.com/item?id=7836626" rel="nofollow">https://news.ycombinator.com/item?id=7836626</a> – 2014-06 (78 comments)<p><i>URL shorteners set ad tracking cookies</i> <a href="https://news.ycombinator.com/item?id=25624112" rel="nofollow">https://news.ycombinator.com/item?id=25624112</a> – 2021-01 (207 comments)<p><i>Link shorteners: the long and short of why you shouldn’t use them</i> <a href="https://news.ycombinator.com/item?id=27462261" rel="nofollow">https://news.ycombinator.com/item?id=27462261</a> – 2021-06 (145 comments)
And just like that, several hundred scientific papers which used git.io links become incorrect <a href="https://scholar.google.com/scholar?hl=en&q=git.io" rel="nofollow">https://scholar.google.com/scholar?hl=en&q=git.io</a><p>Changing the content of papers after they have been published is usually impossible or at least extremely difficult, depending on the publisher.
"<a href="https://git.io/" rel="nofollow">https://git.io/</a>" seems to occur about 200,000 times in source code:
<a href="https://github.com/search?q=%22https%3A%2F%2Fgit.io%22&type=code" rel="nofollow">https://github.com/search?q=%22https%3A%2F%2Fgit.io%22&type=...</a><p>It would be good to write a script to fetch all of those and log their destinations to a CSV file and put that online somewhere. You could even make PRs to all of those projects replacing links with un-shortened versions.<p>I hope github will replace the redirects with a holding page linking where they used to redirect to, rather than just delete them. That way people can report the broken links to the original site and still get to the destination they were intending.
> Out of an abundance of caution due to the security of the links redirected with the current git.io infrastructure, we have decided to accelerate the timeline. We will be removing all existing link redirection from git.io on April 29, 2022.<p>What were the security concerns?
Annoyingly, the CodeQL analysis github actions make use of git.io as a short link to relevant documentation inside action comments.<p>Even right now, the action is still using git.io so regardless of this advisory, that seems like something that should be have been fixed some time ago when git.io was initially put into read only mode
Feels like a punch in the stomach.<p>git.io has its place in the world, namely for creating code comments to Github <i>immutable</i> permalinks (that is, with SHA markers) that would otherwise surpass a conventional column limit, making linters complain.<p>I probably have created dozens of such comments over the years. Now people following those will find nothing.<p>Folks at github should really reconsider their position. Don't expect loyal consumers to keep their trust when you suck at your very job - namely keeping an immutable historic record.
A dump of the shortlink dataset would be appreciated, even if it was only the links that point to public GitHub repos or gists.<p>Link-rot is annoying, but GitHub could do better here.
GitHub has been quite thoughtful about its deprecation timelines before, e.g. with long notice periods and brownouts. They're handling this quite badly.<p>Personally I don't see why they would care that it is used to shorten links to malicious redirects or whatever. But given that they do, the easy fix is to drop the github.io domain but keep the github.com domain. And in the interest of letting people update their URLs, returning the redirect URL as a response body instead of a 302.
This is not a developer-friendly decision.<p>Why can't they leave it working for existing URLs at least?<p>A quick search shows 704,000 code results containing git.io.<p><a href="https://github.com/search?q=git.io&type=code" rel="nofollow">https://github.com/search?q=git.io&type=code</a><p>Edit: actually it is more than 704k, much more it seems.
This made me nostalgic, I remember when vanity URL shorteners were the coolest thing you could have. A new one popped up every few days and every company land grabbed for something custom they could use for social media.<p>Then Twitter updated to make URLs use fewer characters by shortening them on the fly (and showing the original URL to viewers). The URL shortener craze died quickly after.
Sourcegraph CTO here. Does anyone know someone at GitHub or Microsoft we could get in touch with to take over maintenance of git.io? There are hundreds of thousands of references in open source, blog posts, and academic papers that will 404 if git.io is taken down. Sourcegraph would be happy to take over maintenance to preserve these links.
As an owner of <a href="http://git.io/way" rel="nofollow">http://git.io/way</a> and <a href="https://git.io/no" rel="nofollow">https://git.io/no</a> it's a good thing I noticed this on hackernews front page. Otherwise I would've never known! Just changed all of my git.io links where I could find them. I wish they would send out emails for this, but as I remember git.io is an anonymous service.
Glad I made the decision to use my own 5-character domain for URL shortening years ago. Anyone can write a simple URL shortening service in less than half an hour, and you gain flexibility and peace of mind with that little bit of effort.<p>Still, losing all git.io links hurt. I’m certain I have a few old projects with issue explanations, download links, etc. based on git.io. This is handled so poorly it’s ridiculous.
Discussion from the January announcement:
<a href="https://news.ycombinator.com/item?id=30024993" rel="nofollow">https://news.ycombinator.com/item?id=30024993</a> - 56 comments
This is why you should never use url shorteners for publicly addressable content. Using url shorteners contributes to ‘link rot’ and after the domain expires or the service reaches its end of life the link is broken and cannot be resolved anymore.<p>imo, it’s fine for linking to ephemeral content such as submission forms or anything that will not make sense after a certain time. Do not use it for articles and other content, because it will make the resource inaccessible after the service is no longer operational.
Here is a list of open source projects that should update their git.io URLs, ranked in order of popularity: <a href="https://sourcegraph.com/search?q=context:global+https://git.io+count:10000&patternType=literal" rel="nofollow">https://sourcegraph.com/search?q=context:global+https://git....</a>
I will continue my attempt to rescue the word “deprecate” from destruction.<p>> <i>Git.io deprecation</i><p>> <i>As notified in January, we shared our plans to deprecate the service.</i><p>This is not deprecation. This is discontinuation.<p>Deprecation is when you say “we recommend not using this, but it’s still working for now”; at time of deprecation, a schedule of when it will cease to work may be provided, or it could be that it will continue to work indefinitely.<p>The announcement in January <i>was</i> the deprecation. What they’re doing now is the final discontinuation.
Off topic, but I have really grown to despise the phrase "out of an abundance of caution". It's grown so popular during the pandemic when people exercise the absolute bare minimum amount of caution.