This sounds like a bug, not something they deliberately do.
GitHub is aggressively caching raw.github, breaking many use cases
61–70 of 145 posts
Re: GitHub is aggressively caching raw.github, breaking many use cases
#62Earlier quoted context omitted.
How do you see that? At leat in my mobile browser nothing jumps into my eye. This user has contributions to @github, but very few. Edit: Found it. Need to click on one of the achievements. Then the layout changes and it appears in the lower left corner under Organizations.
It doesn't appear to be visible on mobile, only desktop.
Github Mobile app has it too.
Re: GitHub is aggressively caching raw.github, breaking many use cases
#63This seems reasonable to me. Caches should last longer; if you want to be sure of you get the latest version, rename the file. a good trick is to include the hash of the file in the name to get content-addressing à la IPFS.
The commit ID seems to be part of the URL you can use https://raw.githubusercontent.com/burekasKodi/repository.bur... I'm fine with them caching "latest" tbh.
I’m not fine with latest not actually being latest. That defeats the point of the URL.
Re: GitHub is aggressively caching raw.github, breaking many use cases
#64This seems reasonable to me. Caches should last longer; if you want to be sure of you get the latest version, rename the file. a good trick is to include the hash of the file in the name to get content-addressing à la IPFS.
> if you want to be sure of you get the latest version, rename the file. This is a beyond ridiculous statement. It is a BUG that you do not get the latest version of the file when viewing raw, not an error you made that you should address by having a filename driven versioning system. If I'm using Git and GitHub, it's specifically to NOT have to deal with v1, v1.1, final, final_for_real, final_of_the_finalest, this_t…
If you're using GitHub for this reason, you also have protocol that specifically works for that use case.
Re: GitHub is aggressively caching raw.github, breaking many use cases
#65Earlier quoted context omitted.
> if you want to be sure of you get the latest version, rename the file. This is a beyond ridiculous statement. It is a BUG that you do not get the latest version of the file when viewing raw, not an error you made that you should address by having a filename driven versioning system. If I'm using Git and GitHub, it's specifically to NOT have to deal with v1, v1.1, final, final_for_real, final_of_the_finalest, this_t…
Ridiculous is expecting a service you're not paying for to serve files in a way that fits your use case when you've never entered into a contract that guarantees the behaviour you're relying on. You can use Git just fine without GitHub.
Well, I think it’s probably fair for users to expect a site advertising itself as a great web host for git to not serve stale files over web protocols. It’s kinda the entire point of the website.
Maybe it’s a bit questionable to use the raw feature as a content host, but GitHub has intentionally moved pretty fair from plain old git (I believe people call this a “moat”)
I’m sure there are plenty of other players competing for users that would be happy to solve the problem for free.
Re: GitHub is aggressively caching raw.github, breaking many use cases
#66Earlier quoted context omitted.
> if you want to be sure of you get the latest version, rename the file. This is a beyond ridiculous statement. It is a BUG that you do not get the latest version of the file when viewing raw, not an error you made that you should address by having a filename driven versioning system. If I'm using Git and GitHub, it's specifically to NOT have to deal with v1, v1.1, final, final_for_real, final_of_the_finalest, this_t…
If you're using GitHub for this reason, you also have protocol that specifically works for that use case.
But the fact is you can face the problem for literally any GitHub usecase. I will often open a file in raw just to copy-paste a few lines for example, which is not any specific use case.
Re: GitHub is aggressively caching raw.github, breaking many use cases
#67A bug: See https://github.com/orgs/community/discussions/46691#discussi... (Well, if we believe the statement "github engineer here". Of course every clown could write that, too)
[flagged]
Re: GitHub is aggressively caching raw.github, breaking many use cases
#68Earlier quoted context omitted.
> if you want to be sure of you get the latest version, rename the file. This is a beyond ridiculous statement. It is a BUG that you do not get the latest version of the file when viewing raw, not an error you made that you should address by having a filename driven versioning system. If I'm using Git and GitHub, it's specifically to NOT have to deal with v1, v1.1, final, final_for_real, final_of_the_finalest, this_t…
Ridiculous is expecting a service you're not paying for to serve files in a way that fits your use case when you've never entered into a contract that guarantees the behaviour you're relying on. You can use Git just fine without GitHub.
So expecting that a raw file isn't outdated is a special usecase now?
And I don't see where you see that I'm not a paying user? This issue affects every repository, including ones where the user pays.
Re: GitHub is aggressively caching raw.github, breaking many use cases
#69Earlier quoted context omitted.
> if you want to be sure of you get the latest version, rename the file. This is a beyond ridiculous statement. It is a BUG that you do not get the latest version of the file when viewing raw, not an error you made that you should address by having a filename driven versioning system. If I'm using Git and GitHub, it's specifically to NOT have to deal with v1, v1.1, final, final_for_real, final_of_the_finalest, this_t…
Ridiculous is expecting a service you're not paying for to serve files in a way that fits your use case when you've never entered into a contract that guarantees the behaviour you're relying on. You can use Git just fine without GitHub.
[deleted]