[[!comment format=mdwn
 username="daven.quinn@d0ed4e0e5e4462d9a74a5d5a8fbd1b17f85db13e"
 nickname="daven.quinn"
 avatar="http://cdn.libravatar.org/avatar/4811a26fff610f0c9668d183481a7158"
 subject="comment 1 response"
 date="2023-01-16T21:45:35Z"
 content="""
Fair enough, I suppose. However, I think that feedback from early-stage users should be weighted highly, as we interact with \"onboarding\"/\"discoverability\" problems that eventually fade from being users' primary impediments to use.

> git-annex can't be limited to commands that happen to have equivalant git commands.

I'm not suggesting that all commands should have `git` equivalents. Instead, when a commonly used equivalent (or close relative) is available, the name should be mirrored to increase discoverability of common idioms.


> This would encourage drawing a false equivilance with git remote rename.

I'm not quite sure why the equivalence would be false — yes, the commands do somewhat different things. But they both fundamentally rename a remote.

> searching for strained equivilances to git remote commands.

Again, I am not sure the equivalences are so strained. Users should not (and I think broadly won't) expect a git-annex subcommand to do exactly the same thing as a git equivalent. But semantic-level parallelism with git top-level commands, and adopting git's pattern of grouping like functionality into subcommands, could greatly improve discoverability. As it stands, the goals of *preventing confusion between similarly named functionality* and *allowing functionality to be easily found* are in tension. 

Another way to frame my suggestion is to consider the layout of the `git-annex` command line help output. Right now, when seeking assistance, the user is presented with a long list of commands and has to hunt for related functionality (`renameremote`, `enableremote`, etc.) within it. In contrast, when I type `git remote --help`, I see all of the commands for managing remotes in a single, shorter output. It is another nesting level, true, but I think a help page entry of `remote - manages git-annex special remotes` would be easier to parse than the current output.

Anyway, I appreciate your work on this system and consideration of user feedback.

Regards,
Daven
"""]]
