Git.io deprecation
github.blog
github.blog
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?
[1] https://github.blog/2011-11-10-git-io-github-url-shortener/
URL Shorteners – the herpes of the web https://news.ycombinator.com/item?id=570041 – 2009-04 (17 comments)
Url Shorteners: Destroying the Web Since 2002 https://news.ycombinator.com/item?id=660087 – 2009-06 (57 comments)
URL Shorteners are evil, here's one to prove it. https://news.ycombinator.com/item?id=904941 – 2009-10 (57 comments) – ironically dead
Link shorteners hurt the user experience and destroy the Web https://news.ycombinator.com/item?id=7803290 – 2014-05 (89 comments) – dead
The URL shortener situation is out of control https://news.ycombinator.com/item?id=7836626 – 2014-06 (78 comments)
URL shorteners set ad tracking cookies https://news.ycombinator.com/item?id=25624112 – 2021-01 (207 comments)
Link shorteners: the long and short of why you shouldn’t use them https://news.ycombinator.com/item?id=27462261 – 2021-06 (145 comments)
You can't count on anything on the web lasting. You can't count on anything disappearing either.
When you want the web to be ephemeral, "the internet never forgets".
When you want the web to be permanent, the site you remember will be abandoned and lost.
But you don't need to double the problem by making a link rely on two domains and shortening its life.
What's more, if you have the complete original URL, you might be able to use an archive service that might have taken a snapshot, or at least try to guess what was behind the link by looking at it. Shortened URLs are usually inscrutable.
Oh, is that why it’s called a URL shortener!
This is the most important part. Now some smart crawlers figured it out and show you the archived version of the redirect if you got lucky, but so much has been lost because more or less everyone found it aesthetically unpleasing to look at long links. I suppose we weren't aware of the trade-off.
Both archive services have shortcomings of their own related to URL shortening:
- archive.is ironically encourages the use of shortened URLs to its own archived snapshots![0] Its long URLs, which I've never seen used in the wild, are for some reason hidden away in the 'share' menu.
- archive.is stores the original submitted URL in the final snapshot and shows it in the header if is not the same as the ultimately archived URL,[0] but WBM does not.[1]
- WBM mysteriously doesn't work on bit.ly (returning only the message 'Job failed.'[2]), but does work on tinyurl.com. Unfortunately, opaque errors like this are not uncommon with the WBM, errors sometimes as serious as snapshots becoming completely blank years after being taken! Somewhat concerning considering its role as an archive, I'd say. If only the Internet Archive had open-sourced their server like Wikimedia did from the start…
[0] example: https://archive.today/KWDbr
[1] example: https://web.archive.org/web/0/tinyurl.com/3k8mma8k
[2] For example, try http://web.archive.org/save/https://bit.ly/3vO29UB
Aside: It's a bit interesting, considering both current events and archive.is's notoriously unclear ownership (the only common info being the domain's registration to an individual in Prague) that two of the five social media sites in the 'share' menu are VK and LiveJournal. Are those commonly used outside of Russia in recent years?
on edit: this of course does not answer the inscrutability of the url, only the archiving complaint.
Only partially: to other archiving services, a shortened URL from this shortener which also happens to be an archiving service is the same thing as if the shortener didn't provide archival.
The only solution I see is that archive services resolve these shortened URLs when they archive a page and archive the result with it. The second best and probably more reasonable solution is that they maintain a directory (mapping) of shortened URLs to real URLs assuming the mapping does not change.
But one can see it's rapidly a mess right?
I've actually never seen a long link from archive.today in the wild:
http://archive.is/2022.04.26-061642/https://news.ycombinator...
(For the unaware, the Internet Archive's Wayback Machine and archive.today (they've got many TLDs) are well established as the two major general-purpose web archives.)
The only possible solution right now would be to point to the dated content at the Web Archive.
With normal sites and content manipulation there's at least a reputational aspect that tends to stick.
Can I theoretically buy a Domain name outright? Or for 99 years?
I think of my service more like security but it does shorten…
[0]: https://waaard.con
Changing the content of papers after they have been published is usually impossible or at least extremely difficult, depending on the publisher.
I have no idea how to submit shortened URLs to URLTeam, but if anyone can find out I'll be happy to scrape URLs out of that list of Google Scholar PDFs.
Platforms such as https://zenodo.org/ allow for uploading digital artifacts such as publication attachments, supplementary codes or measurement/survey data and assigning them permanently with a DOI.
Zenodo may go down, but maybe some hard disk survives and resolving that DOIs will be possible at some future web system. DOIS are built to last!
I don't know how common it is for these links to have been caught by the archive, but potentially all is not lost.
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.
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.
What were the security concerns?
> Today, git.io is increasingly being used for malicious purposes.
So my guess is they observed an increase use of some number of existing git.io URLs (perhaps where the destination URL was squatted on) being actively used for "malicious" things.
... how? Git.io only redirects to GitHub, isn't it?
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
https://github.blog/changelog/2022-01-11-git-io-no-longer-ac...
git.io has its place in the world, namely for creating code comments to Github immutable permalinks (that is, with SHA markers) that would otherwise surpass a conventional column limit, making linters complain.
I probably have created dozens of such comments over the years. Now people following those will find nothing.
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.
Info going stale seems much worse with commit messages since they can’t even be updated unlike comments.
With `git blame` you can use `-w` to ignore whitespace changes and `-M` to detect moved/copied code; a lot of the time this will help to rapidly find the relevant commit rather than a lint change.
You can also use `git log` on a range of lines of a file: `git log -L 15,23:src/main.rs` and if you add `-p` you'll see diffs as well.
Comments can go out of date, commit messages (if used properly) provide a genuine timeline of the evolution of the code.
9 times out of 10, "why are things the way they are now?" is what I'd like to know.
Occasionally, of course, I would like to know "why things were the way they were x commits ago" and that's when commit messages come in handy. But that's the minority use case for me.
I use `git blame` heavily and find that I can rapidly
understand the intent behind some code by doing so,
assuming the commit messages are well-crafted
But, this bogs down pretty quickly for me. Great for a single line of code, but if I'm trying to understand something that spans multiple methods or multiple files that's a lot of spelunking around the commit messages, which are a mix of whys and whats.
At their best, code comments are a really focused distillation of the current whys and should never ever contain whats.
I always use `git add -p` to only stage relevant portions of my current work, and then usually write a detailed message like this:
Decrease reprojection error threshold to 1.0
With improved calibration, RANSAC has been able to find
a similar number of inliers even with a tighter
threshold, resulting in better triangulations.
<maybe attach some output showing improved reprojection error stats>
threshold=1.0
The problem with churn can be mitigated by telling git to ignore whitespace changes, but it's not perfect. Maybe more helpful is to have a style guide and make it part of your review process so you don't end up with multiple developers doing things like reformatting a multi-line function call to their liking over and over.
Comments explain non-obvious things. For example, "this is a custom search because it was found to be 2.3x faster than .find() for this use case" or "this is sent as a string for backwards compatibility with ExternalRandomApi v1.2" or just walk through a complex algorithm.
I typically only go into archeology mode for two reasons:
1) I found the source of a bug and want to see when it was introduced and why. This is most helpful to prevent reintroducing an old bug, especially in old code lacking unit tests.
2) Someone wrote code that should have been commented, but wasn't.
Then you can change them later ie make links to other tickets or leave comments.
I would also note, for this particular style of URL, that the long URLs are much more useful, as you can read the ref and the path directly, and perhaps thereby bypass the web entirely. The short URL has to be followed to discern its target.
If you don't see the value of not breaking contracts (in the API sense), it is clear to me that your opinion isn't qualified.
Either you own your domain, hardware, software, data, and network -- or you're a tenant in someone else's domain, at your landlord's complete mercy.
Sometimes it's not a bad deal, especially when it's a small landlord whom you have a connection with, other times it can be a raw deal.
You don't have to own all the pieces, but owning your domain name is crucial to avoiding having the rug pulled out from under you like this.
Link-rot is annoying, but GitHub could do better here.
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.
Why can't they leave it working for existing URLs at least?
A quick search shows 704,000 code results containing git.io.
https://github.com/search?q=git.io&type=code
Edit: actually it is more than 704k, much more it seems.
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.
EDIT: https://twitter.com/untitaker/status/1519034010978160641
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.
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.
> Git.io deprecation
> As notified in January, we shared our plans to deprecate the service.
This is not deprecation. This is discontinuation.
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.
The announcement in January was the deprecation. What they’re doing now is the final discontinuation.
This announcement in itself is a deprecation, just like the last one, that additionally announces a future discontinuation.
There is no requirement a deprecated service still works.
If something is half broken you can deprecate it for those relying on the half-broken mess and eventually discontinue it (which is what Github is doing)
Read-only still lets you use it: http://git.io/iEPt8g
The feature can be a stub that prints "no pls" and you're still free to mark it as deprecated (that's more common than one might expect because ABIs are a thing)
> Existing URLs will continue to be accessible, but we encourage using one of the many URL shortening services that are available, instead of git.io, as we will be deprecating the tool in the future.
Semantically, that was clearly a deprecation of the service: it keeps working, but they discourage its use as it will be discontinued in the future. (It was also notice of shutdown of the write parts of the service.)
It is not reasonable to consider today’s notice to be a deprecation (interpreting that as a change in status).
> There is no requirement a deprecated service still works.
This is flatly wrong. The agreed meaning of the word “deprecate” requires that it still works. See https://en.wikipedia.org/wiki/Deprecation for a good overview of the term’s proper usage and accepted meaning.
It's not flatly wrong, you're just stuck on a tautological use of the word "work"... after all how do you deprecate something that doesn't exist?
I used the example below: you can stub out a method with a print statement that says "don't use this" and still deprecate it.
The function still "works" in the most literal sense... it just doesn't do any useful work. It doesn't work.
> Semantically, that was clearly a deprecation of the service: it keeps working, but they discourage its use as it will be discontinued in the future.
You can't call the original a deprecation and say this one is not. Git.io still works (in reduced but extremely meaningful capacity... git.io links all still work) and they're recommending alternatives.
Your other hang up is said they will deprecate something during a depreciation.
That's perfectly allowed if you're actually going to be this pedantic? I will run while I'm running doesn't make it a false statement.
Also to be clear I'd just rather people not be as pedantic as the grandfather comment. Sometimes it's good to hold up a mirror to that end.
> you can stub out a method with a print statement that says "don't use this" and still deprecate it.
That’s not deprecation. That’s breaking the method.
To define “works” somewhat more specifically: deprecation means that functionality is not materially altered from how it was before the deprecation. (You might devise some way of notifying users—e.g. DeprecationWarning in Python, #[deprecated] in Rust—but this does not materially alter functionality.)
The January notice was a deprecation (even if they mislabelled it). This notice is not a deprecation, because the service was already deprecated. This notice defines a sunset timeline, but does not alter the parameters of the deprecation.
It's both. You can even break a feature and deprecate it for that reason. Deprecation comes down to communication.
> deprecation means that functionality is not materially altered from how it was before the deprecation.
No it doesn't. Maybe you really want it to, but it doesn't.
> This notice is not a deprecation, because the service was already deprecated.
That's not how that works... you can deprecate something and deprecate it again. Each notice is the deprecation if you don't realize this I don't know what you're still going on about...
To deprecate something is to recommend against it's use, but it must still be possible to use it without heeding the depreciation.
Removing all the functionality of something and replacing it with a debug message is not depreciation, it's discontinuation.
>> deprecation means that functionality is not materially altered from how it was before the deprecation.
> No it doesn't. Maybe you really want it to, but it doesn't.
Do you accept that your view of deprecation is not compatible with the definition in say, Wikipedia?