From df5a3a6ca4baf23d581443b28bece5586e6a4f5f Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 16 Jan 2023 13:35:14 -0400 Subject: [PATCH] respond and wontfix --- .../Usability_improvements_for_new_users.mdwn | 3 ++ ..._70ecef547308f9b049bd67f3d2f14117._comment | 37 +++++++++++++++++++ 2 files changed, 40 insertions(+) create mode 100644 doc/todo/Usability_improvements_for_new_users/comment_1_70ecef547308f9b049bd67f3d2f14117._comment diff --git a/doc/todo/Usability_improvements_for_new_users.mdwn b/doc/todo/Usability_improvements_for_new_users.mdwn index 5935bbf1f6..6fad95e82d 100644 --- 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 index 0000000000..096e25a0cf --- /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. +"""]] -- 2.30.2