Merge branch 'master' into ospath

doc/todo/compute_special_remote/comment_15_35bc3e4093591f0551433c3a26abd333._comment

@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: comment 13"""
+ date="2025-02-13T16:36:45Z"
+ content="""
+@m.risse earlier you said that it would be bad to 
+	
+> Silently use the old version of "data.grib", creating a mismatch between
+> "data.nc" and "data.grib"
+
+That's what I was getting at when I said:
+
+> But if you already have data.nc file present in a repository, it does not
+> get updated immediately when you update the source "data.grib" file.
+
+So just using files from HEAD for the computation is not sufficient to
+avoid this kind of mismatch. The user will need some workflow to deal with
+it.
+
+Eg, they could recompute data.nc whenever data.grib is updated, and so make a
+commit that updates both files together. But if they're doing that, why does
+the computation need to use files from HEAD? Recomputing data.nc could just as
+well pin the new key of data.grib.
+"""]]

doc/todo/compute_special_remote/comment_16_54204f341ab2c1203d7092cca8fb6b1d._comment

@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: crossing repository boundaries"""
+ date="2025-02-13T17:01:52Z"
+ content="""
+It could be argued that git-annex should recurse into submodules.
+Oddly, I don't remember that anyone has ever tried to make that argument.
+If they did it was a long time ago. It may be that datalad has relieved
+enough of the pressure in that area that it's not bothering many people.
+
+Anyway, I wouldn't want to tie compute special remotes to changing
+git-annex in that way, but I also wouldn't want to rule out adding
+useful stuff to git-annex just because it breaches the submodule boundary
+in a way that's new to git-annex.
+
+Thinking about a command like this:
+
+	git-annex addcomputed foo --to ffmpeg-cut \
+	    --input source=submodule/input.mov \
+	    --value starttime=15:00 \
+	    --value endtime=30:00
+
+That would need to look inside the submodule to find the input key.
+
+When getting the key later, it can't rely on the tree still containing the
+same submodules at the same locations. `git mv submodule foo` would break
+the computation. 
+
+I think that can be dealt with by having it fall back to checking location
+logs of all submodules, to find the submodule that knows about a key.
+
+Deleting a submodule would still break the computation, and that seems
+difficult to avoid. Seems acceptable.
+"""]]

doc/todo/compute_special_remote/comment_17_8bc2bd7f93ac98d55b69ec1e4e6fa487._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 17"""
+ date="2025-02-13T20:10:52Z"
+ content="""
+I've written up a draft interface for programs used by a compute special
+remote: [[design/compute_special_remote_interface]]
+"""]]