followup

doc/todo/lockdown_hooks.mdwn

@@ -24,6 +24,13 @@ write bit, does not need to lockdown the files within it.
 It would be up to the command to decide how to handle the 
 core.sharedRepository configuration.
 
+These could be set in the global gitconfig file. The IncludeIf directive
+can be used to make them be used only for repositories located within a given
+mount point.
+
+git-annex test disables use of global gitconfig settings. There would need
+to be a way to let it use these.
+
 Perfomance:
 
 Hook would be called twice per store/drop of an annexed object, 

doc/todo/lockdown_hooks/comment_2_575c33970014662c664d71e573e718e7._comment

@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-02-05T17:04:36Z"
+ content="""
+Seems likely that there are a couple of different ways to use
+ACLs to remove write access. In the simple case, any existing ACL can be
+overwritten. In other cases, some other existing ACLs will need to be
+preserved and only a single part changed. In some cases, the ACL for a user
+should be changed, in others the ACL for a group.
+
+And there are several different varieties of ACLs (POSIX, NFS, Windows). 
+And there's the immutable bit, which might be wanted in some specific
+circumstances but certianly not by most people.
+
+So it makes sense to me to not embed specific knowledge of this into git-annex.
+
+This feels to me like something that the system administrator is going to
+want to set up. It would mostly be limited to repositories inside a given
+mount point that needs the unusual lockdown method due to using NFS or
+whatever. The global gitconfig can be set up to switch on the config only
+for those repositories, and the system administrator can set up hooks
+for the particular use case.
+
+I don't see why something like datalad would need to worry about this
+detail, any more than they worry about the PATH to system programs or other
+such things that the administrator sets up.
+"""]]