Merge branch 'master' of ssh://git-annex.branchable.com

doc/bugs/Incompatibility_with_git_2.37/comment_2_4d5eb77736e8512affc25e7bdd5190f1._comment

@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="arnaud@c1d1cc612a3921dc06a417301be08a3e125478c4"
+ nickname="arnaud"
+ avatar="http://cdn.libravatar.org/avatar/c0defbf54541c499f6c0464588fc2ad0"
+ subject="Happens only when core.untrackedCache=true"
+ date="2022-07-21T08:23:04Z"
+ content="""
+I did a little testing with potential triggers in my ~/.gitconfig and traced it down to core.untrackedCache=true
+
+With core.untrackedCache=true and git 2.36, everything works as expected. With git 2.37, I get the bug.
+"""]]

doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_24_fb760c2566b6f37ed7378bbcca5875c5._comment

@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 24"
+ date="2022-07-21T14:03:56Z"
+ content="""
+Thank you Joey -- we will give it a shot soonish! (may be we should somehow add \"conda\" devel builds to datalad/git-annex repo ;) ). Possibly unnecessary question just for myself to feel better ;) :
+
+> When appending to a journal file, first read the last byte. If it's not a newline, then seek back to the previous newline, to discard a previous interrupted append.
+
+isn't it racy between \"first read the last byte.\" and then \"If\"? i.e. if some process dumps/flushes more into that file interim, wouldn't you potentially end up with some garbled line? (or there is a lock)
+"""]]

doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities/comment_3_88b58dd27cbff3f046b6f8d1c612f87f._comment

@@ -0,0 +1,50 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 3"
+ date="2022-07-21T20:08:54Z"
+ content="""
+I see that things are slowly moving ahead in that github issue. On a somewhat related note
+I was able to compile with stack on Windows with lts-19.13 by adding the following extra-deps
+to stack.yaml (starting from Win32 onward in the following patch):
+
+[[!format diff \"\"\"
+diff --git a/stack.yaml b/stack.yaml
+index 9b067c82f..27b0fe53c 100644
+--- a/stack.yaml
++++ b/stack.yaml
+@@ -12,19 +12,21 @@ flags:
+     gitlfs: true
+ packages:
+ - '.'
+-resolver: lts-18.13
++resolver: lts-19.13
+ extra-deps:
+ - IfElse-0.85
+ - aws-0.22
+ - bloomfilter-2.0.1.0
+ - git-lfs-1.2.0
+-- http-client-restricted-0.0.4
++- http-client-restricted-0.0.5
+ - network-multicast-0.3.2
+ - sandi-0.5
+ - torrent-10000.1.1
+-- base16-bytestring-0.1.1.7
+-- base64-bytestring-1.0.0.3
+-- bencode-0.6.1.1
+-- http-client-0.7.9
++- aeson-1.5.6.0
++- Win32-2.9.0.0
++- Cabal-3.6.3.0
++- directory-1.3.7.0
++- process-1.6.14.0
++- time-1.11.1.2
+ explicit-setup-deps:
+   git-annex: true
+\"\"\"]]
+
+Yes, that was the newest Win32 I was able to make things work with as stack wasn't able
+to resolve the cross-dependencies involving `Win32`, `directory`, `process` and `time` packages otherwise.
+And if I remember correctly there was something called `haskeline` that also had specific
+requirements.
+"""]]