From 7f28f41c37674561c7996264eefa44e3bae6f48d Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 20 May 2022 13:17:44 -0400 Subject: [PATCH] response --- ..._4_0253bf642148ea853f6d1c8580e09db2._comment | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 doc/internals/lockdown/comment_4_0253bf642148ea853f6d1c8580e09db2._comment diff --git a/doc/internals/lockdown/comment_4_0253bf642148ea853f6d1c8580e09db2._comment b/doc/internals/lockdown/comment_4_0253bf642148ea853f6d1c8580e09db2._comment new file mode 100644 index 0000000000..ffa3d6f0f5 --- /dev/null +++ b/doc/internals/lockdown/comment_4_0253bf642148ea853f6d1c8580e09db2._comment @@ -0,0 +1,17 @@ +[[!comment format=mdwn + username="joey" + subject="""Re: How to disable lockdown in bare repos?""" + date="2022-05-20T17:08:29Z" + content=""" +I think that the annex.freezecontent-command approach is fine. The hook +runs after git-annex changes permissions, and it can add them back if you +want. It is supported since 8.20210630 + +I agree it would be better if gitolite could be modified to only set the +write bits before deleting the repository. It seems to me that gitolite +demonstratably has a bug, because you show it fail to delete everything but +apparently behave as if it succeeded. Perhaps setting the write bits +could be justified to the gitolite developers as a way to make it more robust +when removing a repository, in case some permission problem prevents deleting +the content of a directory. +"""]]