From 0b91c0e3147debbc09708288fbf67ce91b73f7f0 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 7 Apr 2020 13:46:10 -0400 Subject: [PATCH] comment --- ..._01985a25dbdcfe487e28aaeb5823fded._comment | 25 +++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_2_01985a25dbdcfe487e28aaeb5823fded._comment diff --git a/doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_2_01985a25dbdcfe487e28aaeb5823fded._comment b/doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_2_01985a25dbdcfe487e28aaeb5823fded._comment new file mode 100644 index 0000000000..570fb588d3 --- /dev/null +++ b/doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_2_01985a25dbdcfe487e28aaeb5823fded._comment @@ -0,0 +1,25 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2020-04-07T17:28:52Z" + content=""" +Yes, true, git-annex has some inconsistent parsing of these. + +It's certianly at least a bug worth fixing that the Git.Config parser only +supports "true" and not "1" and "on". (And IIRC git-config also has a +special case for true boolean settings that has only the setting in the +config file, without a value -- which git-annex also may not parse.) + +On special remotes, Kyle's right. Same reasoning also applies to +booleans set by git-annex config. I don't immediately see any good way to +add a translation layer to either when things are set, it would be an ugly +addition in both cases. + +I don't feel git-annex necessarily needs to mimic git here in accepting +all those things. It's well known that not all of git's UI choices are good, +and git-annex does not mimic all of them, eg git has some very nasty +positional --switch parsing. + +But readonly and autoenable using true/false while all other special remote +configs uses yes/no is not good UI either. +"""]]