From 35a2f95ff970565db4a10471d7345439d0ed986e Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 9 May 2022 11:19:34 -0400 Subject: [PATCH] comment --- ...ment_2_0c064717d0b85ff4b9df1bada7c6e7ad._comment | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 doc/bugs/add_config_var_preventing_adjusted_branch_mode/comment_2_0c064717d0b85ff4b9df1bada7c6e7ad._comment diff --git a/doc/bugs/add_config_var_preventing_adjusted_branch_mode/comment_2_0c064717d0b85ff4b9df1bada7c6e7ad._comment b/doc/bugs/add_config_var_preventing_adjusted_branch_mode/comment_2_0c064717d0b85ff4b9df1bada7c6e7ad._comment new file mode 100644 index 0000000000..6010c0a569 --- /dev/null +++ b/doc/bugs/add_config_var_preventing_adjusted_branch_mode/comment_2_0c064717d0b85ff4b9df1bada7c6e7ad._comment @@ -0,0 +1,13 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 2""" + date="2022-05-09T15:13:39Z" + content=""" +It might be worth preventing `git-annex init` when in an existing, already +initalized repo from entering an adjusted branch. But re-running `git-annex +init` generally re-does initialization, except for generating a new UUID +and description. If a repo has been moved to a crippled filesystem, +I think it would be reasonable for a user to expect re-running git-annex +init will react to that. (Which can also involve setting annex.pidlock or +disabling annex.sshcaching.) +"""]]