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

doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_18_679ad639cbba7f9a4d28131219d20178._comment

@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="username"
+ avatar="http://cdn.libravatar.org/avatar/3c17ce77d299219a458fc2eff973239a"
+ subject="comment 18"
+ date="2021-10-18T19:54:29Z"
+ content="""
+I wasn't clear enough, or maybe I did something wrong when testing the directory special remote.
+
+When using standard git-annex repositories for everything as explained in comment 14 I get this:
+
+```
+$ git log --graph --oneline
+*   5555555555 (HEAD -> master) amended commit 2
+|\  
+| * 4444444444 (DVD1) DVD1
+*   3333333333  amended commit 1
+|\  
+| * 2222222222 (CD1) CD1
+*   1111111111  init
+```
+
+The master branch tracks only the contents of my local HDD (note that in step 4 I edit the working directory to my liking and amend the automatic ```git-annex sync``` commit), and the CD1 branch contains only what's in that disc and nothing else, such that ```git checkout 2222222222``` or ```git checkout CD1``` replaces everything in the working directory with the contents of CD1, similar to mounting the physical disc and browsing its filesystem.
+
+Using the directory special remote, the contents of my master branch are combined with the contents of the special remote, so the same ```git checkout CD1``` command wouldn't replicate exactly what's on CD1, the master branch directory tree would still be present after the branch switch.
+"""]]

doc/todo/File_deletion_workflow/comment_2_60b54e6bbb37464697b4f5c4ebe561da._comment

@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 2"
+ date="2021-10-19T12:26:33Z"
+ content="""
+> Since this was posted, fsck has stopped complaining about files dropped with `dropunused`.
+
+Thank you!
+
+> I could imagine formalizing this ad-hoc tag into something standard in git-annex.
+
+This is the best option I think; some sort of flag you can set on a key that marks it as unwanted and propagates via the git-annex branch.
+The actual deletions could then be carried out on the individual repos by using a dedicated command (`dropdeleted`?), by the assistant or perhaps even using `sync --content`. 
+
+The important bit is that it shouldn't be synchronous or depend on the repository being reachable directly though; it should be recorded and propagated asynchronously.  
+E.g. in any tree of repos with assistants running (so, no transitive connections), marking a key as deleted in any one of them should result in the key being deleted from all of them.
+
+> But one problem with it is it may not play well in multiuser environments where people have different ideas about what files they want to delete all copies of.
+
+Ah, I didn't consider that. A recycle bin with tracked files is likely infeasible but an untracked one could still be valuable. That's a topic for another issue though.
+
+"""]]

doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_3_09b89df28a3a3dab2f0fbf2f56feafe1._comment

@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 3"
+ date="2021-10-19T13:05:50Z"
+ content="""
+> Mostly people pick on gpg's public key crypto implementation, and mostly I think, because public key crypto is easy to pick at. I have not seen many such arguments about gpg that seem very convincing to me.
+
+Ah, this is not about the underlying algorithms and theories. Those are more than sufficient in our pre-quantum world and, as you said, AGE isn't fundamentally different here.
+
+What I'm mostly concerned about is the quality of the implementation; especially the non-functional aspects like speed, UI and simplicity (some of which also have security implications).
+
+> The way git-annex uses gpg for encryption=shared does not involve public key crypto at all, but uses AES-128, which is about as close as there is to a standard for encrypting things.
+
+The actual encryption is done symmetrically but the encryption of the symmetric key is done asymmetrically if I'm not mistaken.
+
+This is not what age aims to replace though, it functions the exact same from a high level AFAIK; just with a different implementation that satisfies different goals from GPG.
+
+> git-annex already links to an AES implementation for other purposes and could probably bypass gpg and use that, but that smells of implementing your own crypto.
+
+That definitely smells of homebrewed crypto. This is why I would love to see something like age used: It's a pre-made, (supposedly) secure, standardised crypto system/library that you can feed files into and it simply gives you encrypted files back. No faffing about with complex key setups or other brilliant UX anno 1999.
+
+> AGE does not seem to expose any non-public key encryption, so it could not be used for encryption=shared, I think. (Unless perhaps the public/private key pair were stored in the repo as the shared cipher?)
+
+I'm not sure I follow, couldn't you just generate an age keypair and simply store that in the repo?
+
+Does the current gpg-based implementation not do it just like that?
+
+> I don't like the idea of git-annex supporting more than 2 encryption programs, and even 2 seems like 1 too many. Every one will be an ongoing cost. It's not clear to me that there's enough of a benefit to support AGE, or that it would be the best choice for a +1.
+
+Me neither and I understand your point but the problem with that approach is that it leaves absolutely no way to migrate away from GPG.
+
+GPG is a complex beast that will likely need replacement within the next decade and age seems like the most obvious alternative for use-cases like git-annex.  
+Only time can tell whether it actually becomes the new file encryption standard but it seems like the most likely candidate right now.
+
+"""]]