Added a comment
authorasakurareiko@f3d908c71c009580228b264f63f21c7274df7476 <asakurareiko@web>
Tue, 26 Oct 2021 19:54:53 +0000 (19:54 +0000)
committeradmin <admin@branchable.com>
Tue, 26 Oct 2021 19:54:53 +0000 (19:54 +0000)
doc/todo/__91__PATCH__93___Call_freezeContent_after_move_into_annex/comment_2_7671692f4331c625c7f1e0abe83139f2._comment [new file with mode: 0644]

diff --git a/doc/todo/__91__PATCH__93___Call_freezeContent_after_move_into_annex/comment_2_7671692f4331c625c7f1e0abe83139f2._comment b/doc/todo/__91__PATCH__93___Call_freezeContent_after_move_into_annex/comment_2_7671692f4331c625c7f1e0abe83139f2._comment
new file mode 100644 (file)
index 0000000..9bee8aa
--- /dev/null
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="asakurareiko@f3d908c71c009580228b264f63f21c7274df7476"
+ nickname="asakurareiko"
+ avatar="http://cdn.libravatar.org/avatar/a865743e357add9d15081840179ce082"
+ subject="comment 2"
+ date="2021-10-26T19:54:53Z"
+ content="""
+Sorry I missed explaining a few things and made a mistake in the patch. I made my freeze script detect whether the input is inside or outside of .git/annex/objects, so there are no problems with calling freezeContent on something in the working tree. The problem is not calling freezeContent on the final object, because the delete permission can only be denied at that point. The easiest way without compromising the safety of the previous behaviour is to add another freezeContent call after moveFile.
+"""]]