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
ef3457196a
To get old behavior, add a .gitattributes containing: * annex.backend=WORM I feel that SHA256 is a better default for most people, as long as their systems are fast enough that checksumming their files isn't a problem. git-annex should default to preserving the integrity of data as well as git does. Checksum backends also work better with editing files via unlock/lock. I considered just using SHA1, but since that hash is believed to be somewhat near to being broken, and git-annex deals with large files which would be a perfect exploit medium, I decided to go to a SHA-2 hash. SHA512 is annoyingly long when displayed, and git-annex displays it in a few places (and notably it is shown in ls -l), so I picked the shorter hash. Considered SHA224 as it's even shorter, but feel it's a bit weird. I expect git-annex will use SHA-3 at some point in the future, but probably not soon! Note that systems without a sha256sum (or sha256) program will fall back to defaulting to SHA1. |
||
|---|---|---|
| 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 | ||
| Options.hs | ||
| README | ||
| Remote.hs | ||
| Seek.hs | ||
| Setup.hs | ||
| test.hs | ||
| Types.hs | ||
| Upgrade.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/>