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
8b56d6b283
In a situation where there are two repos that are diverged and each pushes in turn to git-remote-annex, the first to push updates it. Then the second push fails because it is not a fast-forward. The problem is, before git push fails with "non-fast-forward", it actually calls git-remote-annex with push. So, to the user it appears as if the push failed, but it actually reached the remote, and overwrote the other push! The only solution to this seems to be for git-remote-annex push to notice when a non-force-push would overwrite a ref stored in the remote, and refuse to push that ref, returning an error to git. This seems strange, why would git make remote helpers implement that when it later checks the same thing itself? With this fix, it's still possible for a race to overwrite a change to the MANIFEST and lose work that was pushed from the other repo. But that needs two pushes to be running at the same time. From the user's perspective, that situation is the same as if one repo pushed new work, then the other repo did a git push --force, overwriting the first repo's push. In the first repo, another push will then fail as a non fast-forward, and the user can recover as usual. But, a MANIFEST overwrite will leave bundle files in the remote that are not listed in the MANIFEST. It seems likely that git-annex will eventually be able to detect that after the fact and clean it up. Eg, it can learn all bundles that are stored in the remote using the location log, and compare them to the MANIFEST to find bundles that got lost. The race can also appear to the user as if they pushed a ref, but then it got deleted from the remote. This happens when two two pushes are pushing different ref names. This might be harder for the user to notice; git fetch does not indicate that a remote ref got deleted. They would have to use git fetch --prune to notice the deletion. Once the user does notice, they can re-push their ref to recover. Sponsored-by: Jack Hill on Patreon |
||
|---|---|---|
| Annex | ||
| Assistant | ||
| Backend | ||
| Build | ||
| CmdLine | ||
| Command | ||
| Config | ||
| Database | ||
| debian | ||
| doc | ||
| Git | ||
| Limit | ||
| Logs | ||
| Messages | ||
| P2P | ||
| Remote | ||
| RemoteDaemon | ||
| standalone | ||
| static | ||
| templates | ||
| Test | ||
| Types | ||
| Upgrade | ||
| Utility | ||
| .appveyor.yml | ||
| .codespellrc | ||
| .ghci | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| Annex.hs | ||
| Assistant.hs | ||
| Author.hs | ||
| Backend.hs | ||
| bash-completion.bash | ||
| Benchmark.hs | ||
| BuildFlags.hs | ||
| BuildInfo.hs | ||
| CHANGELOG | ||
| CmdLine.hs | ||
| Command.hs | ||
| Common.hs | ||
| Config.hs | ||
| COPYRIGHT | ||
| Creds.hs | ||
| Crypto.hs | ||
| git-annex.cabal | ||
| git-annex.hs | ||
| git-remote-annex | ||
| git-union-merge.hs | ||
| Git.hs | ||
| Key.hs | ||
| Limit.hs | ||
| Logs.hs | ||
| Makefile | ||
| Messages.hs | ||
| NEWS | ||
| README | ||
| Remote.hs | ||
| Setup.hs | ||
| stack-lts-18.13.yaml | ||
| stack.yaml | ||
| Test.hs | ||
| Types.hs | ||
| Upgrade.hs | ||
git-annex allows managing large files with git, without storing the file contents in git. It can sync, backup, and archive your data, offline and online. Checksums and encryption keep your data safe and secure. Bring the power and distributed nature of git to bear on your large files with git-annex. For documentation, see doc/ or <https://git-annex.branchable.com/>