respond and wontfix

diff --git a/doc/todo/Usability_improvements_for_new_users.mdwn b/doc/todo/Usability_improvements_for_new_users.mdwn
index 5935bbf1f6d87b439a5de112f5b33224b352af7a..6fad95e82d916c374a061906411f2425b6fcec1a 100644 (file)
--- a/doc/todo/Usability_improvements_for_new_users.mdwn
+++ b/doc/todo/Usability_improvements_for_new_users.mdwn
@@ -16,3 +16,6 @@ It's worth noting that such changes could happen alongside the current commands
 has recently gone through a similar process to simplify the semantics of some of its commands. I'd ask for such changes to be considered.
 
 Daven
+
+> [[wontfix|done]] at least for the listed things, for reasons explained
+> in my comment below. --[[Joey]]

diff --git a/doc/todo/Usability_improvements_for_new_users/comment_1_70ecef547308f9b049bd67f3d2f14117._comment b/doc/todo/Usability_improvements_for_new_users/comment_1_70ecef547308f9b049bd67f3d2f14117._comment
new file mode 100644 (file)
index 0000000..096e25a
--- /dev/null
+++ b/doc/todo/Usability_improvements_for_new_users/comment_1_70ecef547308f9b049bd67f3d2f14117._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-01-16T17:16:54Z"
+ content="""
+> `git annex info` has no equivalent `git info`
+
+git-annex can't be limited to commands that happen to have equivilant git
+commands. `git annex drop` also has no equivilant in git, but is
+fundamental to git-annex.
+
+If you're thinking of `git annex info` as equivilant to `git remote` in 
+listing remotes, that does not consider everything the info command does.
+
+> git annex remote should ideally return a list of remotes for parallelism
+
+`git remote` lists all remotes including git-annex special remotes,
+so `git annex remote` would be unnecessary duplication.
+
+> git annex renameremote -> git annex remote rename
+
+This would encourage drawing a false equivilance with `git remote rename`.
+
+I'm also not convinced that stacking subcommands 3 levels deep is a good
+idea. The user has to dig through every level to find something then.
+
+There's also an intentional similarity in naming between `git annex init`
+and `git annex initremote`, which I think makes sense and helps users
+learn and remember the latter command after having first learned the former. 
+And `enableremote` and `renameremote` then flow naturally from that.
+This is, IMHO, a more natural learning flow than searching for strained
+equivilances to `git remote` commands.
+
+I do think that `git annex add` has a very good reason to parallel `git
+add`, and if there are other git-annnex commands that could directly
+parallel a git command like that and don't, that would be worth addressing.
+"""]]