Added a comment: comment 1 response
This commit is contained in:
parent
e42ac8844e
commit
be6aec3100
1 changed files with 29 additions and 0 deletions
|
@ -0,0 +1,29 @@
|
|||
[[!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
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue