mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

respond and wontfix

Browse source
This commit is contained in:
Joey Hess 2023-01-16 13:35:14 -04:00
parent 8955a9c7d2
commit df5a3a6ca4
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 40 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

3
doc/todo/Usability_improvements_for_new_users.mdwn
View file

@ -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]]

37
doc/todo/Usability_improvements_for_new_users/comment_1_70ecef547308f9b049bd67f3d2f14117._comment Normal file
View file

@ -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.
"""]]