How to permalink to a gist's raw file

README.md

Problem: When linking to the raw version of a gist, the link changes with each revision.

Solution:

To return the first file from a gist: https://gist.github.com/[gist_user]/[gist_id]/raw/

• Example: https://gist.github.com/atenni/5604522/raw/
• Works even when you change the filename.

To get a file from multi–file gist: https://gist.github.com/[gist_user]/[gist_id]/raw/[file_name]

• Example: https://gist.github.com/atenni/5604522/raw/README.md

(via: http://stackoverflow.com/a/14529686)

Or raw.githack.com

👍

How did you get such short a gist_id in your examples? I realise git hashes can often be shortened but it's not happening for me:

https://gist.githubusercontent.com/inspector71/59e5598/raw/

returns a 404 whereas:

https://gist.githubusercontent.com/inspector71/59e559824edfead1b0d3366ce402a687/raw

returns expected result.

Thanks! 👍

Thanks mate!

Tks

Here's a related StackOverflow question which is of high-value to this thread

Thanks! 👍 👍

@Asbra, No, it links to the latest revision. But GreaseMonkey or TamperMonkey doesn't detect it as an userscript, so the install screen doesn't appear.

@revolter -- As long as the file is correctly named (i.e., ending with .user.js or .user.css) the full format should work, even for single-file gists. I tested this with both Stylus and Greasemonkey, and they pick up the files correctly and automatically ask to install: https://gist.github.com/[gist_user]/[gist_id]/raw/scriptname.user.js

Thanks !!

I'm using https://gist.githubusercontent.com/[username]/[gist_id]/raw/[filename].

I use like so...
curl -o "$USERPROFILE/[filename]" -H "Cache-Control: no-cache" https://gist.githubusercontent.com/[username]/[gist_id]/raw/[filename]

Btw, this is like the only place that specifies the filename part so thank you!
👍

An essential tip for those hosting their userscripts on GitHub Gist

Since userscript hosts (e.g. GreaseMonkey, ViolentMonkey, TamperMonkey) require the links to userscripts to end in user.js to automatically detect, install and update them, you should use https://gist.github.com/[gist_user]/[gist_id]/raw/[file_name] even for single file gists.
Don't forget to set the link as both @updateURL and @downloadURL in the metadata, otherwise the userscript host may assume the versioned download link as an override to updates link if a user installs it by clicking on the Raw button on the gist page instead.

Example

Here's one of my userscripts that I managed to make properly updatable:
https://gist.githubusercontent.com/Erquint/ec4f688c7d6d9ea2ccddff8acb3a8415/raw/FWPMP.user.js
Notice the @updateURL and @downloadURL metadata. The rest is optional

Awesome findings. With this, the permalink will always use the latest version

If you need to use a URL shortener, you can use the official GitHub shortener: https://git.io/

I have a solution for anyone wanting to embed a gist from use the raw URL without the revision number.

With revision:

• https://gist.githubusercontent.com/USERNAME/GIST_ID/raw/REVISION/FILENAME

At a guess, this actually worked without revision:

• https://gist.githubusercontent.com/USERNAME/GIST_ID/raw/FILENAME

I wrote about it here in the context of Docsify.

Thank you guys!! It's helped me a lot!

@MichaelCurrin - everyone else already wrote the same here, years before your "solution" epiphany

Yes as I posted without reading all the comments.

I also added to embed section of the docsify site so this approach be found there easier

https://docsify.js.org/#/embed-files?id=embed-a-gist

https://github.com/docsifyjs/docsify/pull/1238/files

Best answers imo would be

https://gist.github.com/raw/[ID]/[REVISION]/[FILE]

or

https://gist.githubusercontent.com/raw/[ID]/[REVISION]/[FILE]

[ID] is necessary
[REVISION] can be omitted to get the latest revision
[FILE] can be omitted to get the first file

I'm also wondering how did he get SO SHORT url (with short hash) in the first place:

https://gist.github.com/atenni/5604615

I'm suspecting back in 2013 Github allowed to use such shorter urls, and it's now impossible to make. But I wonder if I'm wrong

I'm also wondering how did he get SO SHORT url (with short hash) in the first place:

https://gist.github.com/atenni/5604615

I'm suspecting back in 2013 Github allowed to use such shorter urls, and it's now impossible to make. But I wonder if I'm wrong

yeah maybe

This is URL worked for me. It will update after 4-5 min, I think so.

https://gist.githubusercontent.com/King1037/bd9861c08b86ac158d426ac91d14995d/raw/d956873ea1468sdfcca425c6cb2d0f7b63f8f4cdd/Ldsdfyer.fd.css

You just delete the text after Raw.
https://gist.githubusercontent.com/USERNAME/GIST_ID/raw
https://gist.githubusercontent.com/King1037/bd9861c08b86ac158d426ac91d14995d/raw

Thanks, that was nice: works for secret gists too.

You can use query parameters to get around caching if you want fast updates, i.e. every time you make a request append something like ?cache-bust=(some random url-safe string) to the URL. As far as I can tell, any query string works, so you can omit the cache-bust= if you want, or use donkey-poo= if you feel so inclined.

@rjb3977, usually, an underscore and the current timestamp are used for this: ?_=1617443829.

I found this discussion after looking into it myself. Here's what I've got:

• GIST is NOT meant to behave like a repository. It is a Front End technology.
• Without cache busting, updates take quite a while... Longer than I was going to wait to measure how long exactly.
• WITH cache busting, you can reduce the latency of updates to ~30-60s, but there IS STILL LATENCY.

Here's what I used to observe and measure changes.
Note that I was adding a, b, c... to line 4 character 1 (after the pound/hash sign) every time I saw the change in the cli.

while true; do line=$(curl -s https://gist.githubusercontent.com/raw/2bf5c315a7895193ddc3fe647ef3976b/detect-ci.sh?cache-bypass=$(date +%s) | sed '4q;d'); echo "$(date) -- ${line:1:1}"; sleep 1; done

So, this should be good enough for MOST applications. Mileage may vary.
And there's always a risk that GH will change their caching behavior for these assets.

Nice. Exactly what I needed, thank you! 🙏
I think this should be the default URL, or GitHub should at least be more explicit about this difference...