Hacker News Reader

Comment by Laaas | Hacker News Reader

This 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.

View on HN

I thought the content is more important than getting whatever quickly...

Rename the file to get what you want, am I the only one finding that a very strange approach?

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.

I get the issue but I do strongly feel that you should expect http resources to be cached. It's so common of a thing expecting it to never be cached is unreasonable as a design.

I would expect the headers to make this clear, however.

I actually don’t. Git already has a file on the filesystem. Serving a plain file is as close to caching as you are going to get.

There's a hard limit on that - the speed of light.

You can't know what the actual latest is, only some cached value. The actual value may have changed while the message is in flight

Guess we may as well throw our handa up in the air then and set a 14 year cache ttl.

Seeing as it’s git, can’t you just do content based hashing through the commit hash?

And I’d assume the GitHub api has a way to get the hash for the head of a branch?

I don’t know, I guess the entire point of GitHub is to be able to obtain up-to-date files, so maybe they should just improve the caching.

So we are back to file_v1, file_v1.1, file_v1.2 etc?

Nah, file_v1_final_final_REALLY_final

No, we are where we should have always been:

    > GET /file/latest HTTP/1.1
    < HTTP/1.1 302 Found
    < Location /path/to/real/file/hash.tar.gz

Sure... but their CDN is caching the results for /file/latest, so they'd either have to handle cache expiry differently or the same bug would happen.

Per RFC 2616:

> This response is only cacheable if indicated by a Cache-Control or Expires header field.

Like OpenVMS makes it on Filesystem level where the highest version is the "real" one:

Blupblub;1 Blupblub;2 --> Blupblub;2 = Blupblub

Actually a good idea ;)

So we need to use file_dec_2, file_nov_2, the sort of hacks version control systems were meant to replace?

You can use git or use the commit sha, you only need to name the files if you refuse to use the provided versioning and tooling and want GitHub to act as a file host.

> 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_time_its_really_final.

Your suggestion to work around this GitHub bug is to essentially not use Git. Ridiculous.

No, using git works just fine, as does specifically referencing the version want.

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.

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.

Welp, is it in your SLA?

The CAP theorem certainly isn't new, and it's unreasonable to think GitHub has solved it

Who says I'm not paying for Github? But a Git porcelain that fails to show the version of a file it claims it's showing is a Git porcelain with a bug in it, regardless.

You don't have to take my word for it! https://github.com/orgs/community/discussions/46691#discussi...

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.

Reply on news.ycombinator.com