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
12243d2279
The bug was that with --json, output lines were sometimes doubled. For example, git annex init --json would output two lines, despite only running one thing. Adding to the weirdness, this only occurred when the output was redirected to a pipe or a file. Strace showed two processes outputting the same buffered output. The second process was this writer process (only needed to work around bug #624389): _ <- forkProcess $ do hPutStr toh $ unlines paths hClose toh exitSuccess The doubled output occurs when this process exits, and ghc flushes the inherited stdout buffer. Why only when piping? I don't know, but ghc may be behaving differently when stdout is not a terminal. While this is quite possibly a ghc bug, there is a nice fix in git-annex. Explicitly flushing after each chunk of json is output works around the problem, and as a side effect, json is streamed rather than being output all at the end when performing an expensive operaition. However, note that this means all uses of putStr in git-annex must be explicitly flushed. The others were, already. |
||
---|---|---|
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/>