bisected to f0c046f016aab6485eea57101df953895728e8b4, "re-probing of annex.url for annex+https on connection failure".

The CHANGELOG file is what you want I think.

I've updated the website re MacPorts.

I suspect it may even need macOS 15. That's the OS that the build is happening on. I don't think it makes sense to include the supported OS version in the directory name really; it's unlikely there would be 2 incompatible versions that both would have builds happening.

Also in case it helps someone else later, as best I can tell the release notes are in the git repository as doc/news/version_10.20xxxxxx.mdwn, but it seems like the older release notes get deleted when newer ones are added (at a guess, to keep ~4 release notes showing up on the news page).

This makes reviewing the release notes since an older release somewhat more difficult than it might be, as it seems like the only record of the older release notes is as deleted files, in the git history.

I ended up coming up with:

git clone git://git-annex.branchable.com/ git-annex
cd git-annex/doc/news
git log --stat f1985eabce137adb8851cbbaea1fa8474406f7b5..HEAD . | egrep '^commit|10.2026.*\+\+\+\+\+\+' | grep -B 1 doc/news | grep -v '^--' | sed 'N;s/\n/ /; s/^commit/git show/; s/  doc/:doc/; s/mdwn.*$/mdwn/' | tac | sh -x

to see the release notes for 2026, in chronologically increasing order (ie oldest to newest). Where the magic git commit hash was found by searching with "git log" for the last 2025 / first 2026 commit to doc/news, since the version I found that ran for me (on macOS 10.15) was the last 2025 standalone build, and thus I wanted to know what had changed since then.

(Possibly older news articles could be git mv-ed to an archive directory rather than git rm-ed to make this easier in future, without cluttering up the news page?)

Anyway skim reading the least year's worth of release notes (from the above command, and some slight tidying up), I don't see much that an internal-only git annex remote-only would particularly need before the various October 2026 fixes (which I can't easily have due to build dependencies not supporting macOS 10.15). The only thing that stood out as potentially desirable is the hash performance improvements in git-annex 10.20260624, but for this mostly-archivable, infrequently updated use case I can probably live without those too.

Ewen

For anyone else finding this issue and wondering, it appears that at least git-annex standalone build for macOS from 2025 does run on macOS 10.15 / Catalina still.

wen@dagoba:~$ uname -a
Darwin dagoba 19.6.0 Darwin Kernel Version 19.6.0: Tue Jun 21 21:18:39 PDT 2022; root:xnu-6153.141.66~1/RELEASE_X86_64 x86_64
ewen@dagoba:~$ git annex version
git-annex version: 10.20251118-g9ba1afcff4f513d938763a45488ab392747b2704
build flags: Assistant Webapp Pairing FsEvents TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV Servant OsPath
dependency versions: aws-0.25.1 bloomfilter-2.0.1.2 crypton-1.0.4 DAV-1.3.4 feed-1.3.2.1 ghc-9.10.2 http-client-0.7.19 persistent-sqlite-2.13.3.1 torrent-10000.1.3 uuid-1.3.16 yesod-1.6.2.1
key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL GITBUNDLE GITMANIFEST VURL X*
remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg rclone hook external compute mask
operating system: darwin x86_64
supported repository versions: 8 9 10
upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
ewen@dagoba:~$ 

Obtained by following the instructions on the kitenet download page to check out the git annex containing the references to archive.org downloads of old builds, and then using git log to find an "end of 2025" commit of git-annex.dmg, doing a git checkout of that commit, and then a git annex get git-annex.dmg to download the file (from the web, aka archive.org). Note that since the uploads to archive.org are a git annex remote, they're uploaded by hash filename, and not particularly navigable without the git annex archive as metadata.

(While "a year old" might seem rather old, the "old laptop as a git annex disk server" this upcycled laptop is replacing has an even older git annex, so this is still a substantial version upgrade!)

Likely some of the earlier 10.2026xxxx will also run on macOS 10.15 / Catalina, but since I'm forced to run a git-annex before the "late 2026" security updates (eg, eMudhra "4 as a private key") anyway, in this specific use case (internal only git annex remote) I'm not sure there's much to be gained by trying to find the newest build that still runs. (My guess is "before macOS 27 came out", but likely older than that, since it seems "dependency builds switched to depending on macOS 13/14 SDK" is the breaking things. And from what I've found of NodeJS / dotNet etc similar bugs that specific macOS SDK function was added in macOS 13 or earlier.)

Ewen

As additional context, it looks like MacPorts does now have a build of git-annex, although it seems infrequently updated (Version: 10.20260316, Updated: 7 months, 2 weeks ago). It too doesn't support macOS 10.15 / Catalina any longer.

But maybe it'd be worth linking from the OSX page if you think "a build, but maybe old" is worth users considering. (By contrast I think HomeBrew has active git-annex users, as it seems to get updated/rebuilt fairly soon after a new release.)

Ewen

The new git-annex-transfers is a more targeted take on git-annex activity.

As far as I can see, core.worktree is the only config setting that is relative to the path of the gitdir.

Changing the gitdir to be where the symlink points to does not seem like a good idea, it would affect git-annex code that creates symlinks pointing into the gitdir.

Also, git rev-parse --git-dir is just ".git" in this situation, so even git internally does not follow the symlink manually, except presumably when resolving core.worktree.

So, I've fixed this only in the core.worktree handling code in updateLocation.

It does work for special remotes, but not for git remotes.

Ah, well that explains why we saw different behavior

Just for the record, I don't currently have a use-case for proxies, and the one I have in mind for the future would only involve a special remote that is read-only by itself already, so I don't see any urgency for this issue. Still, good to have it logged.

It does work for special remotes, but not for git remotes.

I think the reason for the difference is that Annex.Proxy has proxyGitRemoteSide and proxySpecialRemoteSide. The former opens a P2P connection to the proxied remote's git-annex-shell, and so it does not access the remote via a Remote object like the latter does. So the fact that the Remote has methods that have been made readonly has no effect.

So probably proxySpecialRemoteSide needs to look at annex-readonly and then somehow limit the P2P connection to ServeReadOnly. But I don't think there is actually any way to do that, short of modifying git-annex-shell or somehow injecting GIT_ANNEX_SHELL_READONLY into its environment when running it. So supporting it might involve consuming the P2P protocol and filtering out writes before relaying it. Unfortunately, that would add copying of DATA, so could be a significant slowdown.