CI to automate build of cargo lockfiles on different Alpine releases for git-annex aports
https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/community/git-annex
ecfcb41abe
The code explicitly switches from HEAD to GET for most redirects. Possibly because someone misread a spec (which does require switching from POST to GET for 303 redirects). Or possibly because the spec really is that bad. Upstream bug: https://github.com/haskell/HTTP/issues/24 Since we absolutely don't want to download entire (large) files from the web when checking that they exist with HEAD, I wrote my own redirect follower, based closely on the one used by Network.Browser, but without this misfeature. Note that Network.Browser checks that the redirect url is a http url and fails if not. I don't, because I want to not need to change this code when it gets https support (related: I'm surprised to see it doesn't support https yet..). The check does not seem security significant; it doesn't support file:// urls for example. If a http url is redirected to https, the Network.Browser will actually make a http connection again. This could loop, but only up to 5 times. |
||
|---|---|---|
| Annex | ||
| Backend | ||
| Build | ||
| Command | ||
| Common | ||
| debian | ||
| doc | ||
| Git | ||
| Logs | ||
| Messages | ||
| Remote | ||
| Types | ||
| Upgrade | ||
| Utility | ||
| .gitattributes | ||
| .gitignore | ||
| Annex.hs | ||
| Backend.hs | ||
| CHANGELOG | ||
| Checks.hs | ||
| CmdLine.hs | ||
| Command.hs | ||
| Common.hs | ||
| Config.hs | ||
| configure.hs | ||
| Crypto.hs | ||
| git-annex-shell.hs | ||
| git-annex.cabal | ||
| git-annex.hs | ||
| git-union-merge.hs | ||
| Git.hs | ||
| GitAnnex.hs | ||
| GPL | ||
| Init.hs | ||
| INSTALL | ||
| Limit.hs | ||
| Locations.hs | ||
| Makefile | ||
| mdwn2man | ||
| Messages.hs | ||
| NEWS | ||
| Option.hs | ||
| README | ||
| Remote.hs | ||
| Seek.hs | ||
| Setup.hs | ||
| test.hs | ||
| Types.hs | ||
| Upgrade.hs | ||
| Usage.hs | ||
git-annex allows managing files with git, without checking the file contents into git. While that may seem paradoxical, it is useful when dealing with files larger than git can currently easily handle, whether due to limitations in memory, checksumming time, or disk space. For documentation, see doc/ or <http://git-annex.branchable.com/>