A am a newbie, sorry if this is a stupid question, for some reason when I go to any repo, click on commits, then click on any commit, browse files, then download ZIP, it will redirect me to codeload.github, with a page saying 404: Not found, This will happen regardless of file, device (pc and mobile), with and without extensions, i have tried using a vpn, or simply just logging out. Nothing worked, this has been occuring for days. This is occuring on all repos i try this on, including my own.
Hi @Bits360, welcome to the community,
You can download a repository/branch with ‘Download ZIP’
https://github.com/octocat/Hello-World or https://github.com/octocat/Hello-World/tree/octocat-patch-1
You cannot for example go into repository commit, browse files to something like this URL
and then Download Zip of that commit. I can see this may be confusing as there is a Download Zip button displayed.
If you are just starting with Github, there are some great free Learning labs at https://lab.github.com/
an update, Its a bug and GitHub support are working on it
Why cant I just go into a commit and download zip? That seems like an absolutely enormous design flaw.
I believe its a bug recently introduced and support are now aware, so hopefully it will be fixed soon
Give a try again to see if all is ok for you also.
Hi @byrneh–I was moderating through the backlog of uncategorized posts and stumbled on a few of your responses. Thank you for being such a thoughtful contributor in the community!
Thankyou @tuves for being thoughtful to say so
This very same bug has come back with a vengeance, it seems, sometime after Sept 15th 2021 (the last time I successfully used that GitHub feature…).
I often need to download as an archive (.zip) the snapshot of a repo at a given commit, e.g. let’s say I want to download via my browser, using GitHub’s web front-end, snapshot
59719a905c of FFmpeg/FFmpeg:
I would then click the
Browse files button, taking me to
then click the green
Code button and select
But, as you can see in the link preview in the bottom, the archive to be downloaded is ALWAYS the HEAD of the default branch (“master” in the case of FFmpeg), not the one corresponding to snapshot
Currently, I have to jump hoops to achieve what I want (involves manually composing download links based on existing GitHub APIs, that part is probably out of the scope of this report ), but I’d really like to see this issue fixed in a timely fashion; this isn’t entitlement on my part, my workflow relies heavily on that feature of the front-end…
I believe the resurgence of this quite nasty bug has the same root cause as
which was recently submitted… Indeed, only the default branch of a repo can be now downloaded as an archive, not a user-selected different branch…
Hopefully, this report will eventually reach appropriate GitHub Support staff, be troubleshot and, fingers-crossed, be resolved in a successful manner…
Yeah - we’re experiencing the same issue. Was working fine about a month or so ago
I honestly hope you’re OK under these “pandemic” times, no doubt difficult for a lot of people the globe around…
I noticed you’re one of GitHub staff , pardon me for asking, but are you in any position to channel this bug report to the appropriate GitHub Support Team?
This inconvenience of no more being able to download zips of specific commits (via the web front-end) has put a serious dent on my workflow; it hasn’t yet been acknowledged as a bug by any GitHub representative, nor is there any timeline announced for an eventual fix…
I truly hope this wasn’t a change by design, as this basic web front-end feature had been there for ages (… and it’s still being offered by the competition… ).
Patience is a virtue, I know, I am inclined to wait as much as anyone, but I’ve been going already for 10 days with the feature broken…
I checked with our Support folks and it looks like the issue was addressed and fixed a few days ago. However, in the future, please submit a ticket to our Support Team as that will increase visibility to the right people to help. Thank you for your patience!
Many thanks @tuves for your kind and thoughtful reply! ; apologies for not getting back to you sooner, RL issues…
I can confirm the fix you talked about has indeed been propagated to GitHub nodes close to my physical location (South-Eastern Europe), for “closure” I’m attaching below a screengrab demonstrating the fix is now working on the very same repo+commit it wasn’t working in my previous bug report:
My gratitude extends to all those responsible for the fix, you included !
I’m also pleased to confirm that the related issue reported (by others) in posts 202016 and 202830 has been also successfully resolved .
As a sort of side note, the new code doesn’t appear to be identical to the one prior to the manifestation of the bug (i.e. before ca. 2021-09-15), because my most favourite (be it third party) GitHub userscript, GitHub download zip, is still broken; however, I realise this isn’t something to blame GitHub about, rather an issue to take directly with that userscript author…
With all due respect, prior to posting in this thread, I gave a thorough read to your colleague’s nice article below:
and my understanding is (please correct me if I got it wrong…) that
github.com bugs like the one I experienced should be forwarded to
github.community (i.e. here ), unless they involve “sensitive data” and/or “security vulnerabilities” (neither case applies to my bug… ); if one cares to read the whole thread there, one will find that even if
github.com bugs have been reported via the “Contact” form, Support Team will, most likely, direct the reporter back to the community here…
So, at the end of the day, I think I posted in the recommended “place”…
Best regards, take care and thanks again!