Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

CLI UX need refinements #2

Closed
afranke opened this issue Jul 21, 2018 · 17 comments
Closed

CLI UX need refinements #2

afranke opened this issue Jul 21, 2018 · 17 comments
Labels
area/cli Relates to the CLI RFC Request for comments

Comments

@afranke
Copy link

afranke commented Jul 21, 2018

To be consistent with git core, I suggest the following commands and behaviours:

  • git bug lists bugs (replaces git bug ls)(similar behaviour to remote and branch)
  • git bug --help shows available commands (replaces git bug commands)
  • git bug add creates a new report (replaces git bug new as commands should be verbs)
@MichaelMure
Copy link
Collaborator

Thanks, will do !

I recently switched to use cobra as a lib for command line parsing and stuff. Did you check ? The root command should list properly the subcommands as well as provide suggestion for typos.

git bug commands was designed to be able to build command line completion tool and to generate documentation, but now that cobra does that (check the doc folder), it might be removed.

I guess I should follow the same pattern for other commands as well ? For labels it should be:
git bug label <id> list the labels
git bug label add <id> add a label
git bug label remove <id> remove a label

That's quite a lot of keystrokes though...

I was also thinking about having a command like git bug select <id> that would select a bug as default for future edit with other commands. Good or bad idea ?

@ermik
Copy link

ermik commented Aug 3, 2018

As long as there is a Y/N prompt for any default options — they wouldn't hurt. Keystrokes are handles by shell aliases, which just needs to be explained to some people.

Project seems awesome.

@afranke
Copy link
Author

afranke commented Aug 3, 2018

I guess I should follow the same pattern for other commands as well ?

Yes, consistecny is important and completion should reduce the amount of keystrokes anyway.

I was also thinking about having a command like git bug select that would select a bug as default for future edit with other commands. Good or bad idea ?

Good idea. git already has a few interactive subcommands like git add -p which you may want to mimic.

@MichaelMure MichaelMure changed the title Use commands and options that are in line with existing git commands CLI UX need refinements Aug 3, 2018
@MichaelMure
Copy link
Collaborator

MichaelMure commented Aug 3, 2018 •
edited
Loading

Project seems awesome.

\o/

Just so you know, I'm waiting for the core feature to stabilize and to have a consistent plan for all the commands to tackle this problem.

Another question, should git bug simply run the interactive UI (so git bug termui would be removed) ? I expect that most people would use the interactive UI so it would make sense to launch it easily. It does hide a bit the command's help for the newcomer though ...

UX peoples, please send help :)

@ermik
Copy link

ermik commented Aug 3, 2018

Run the interactive by default. Provide --ci and similar options to allow no-TTY execution (e.g. the build / continuous integration system files bugs on failure automatically).

@MichaelMure MichaelMure added the RFC Request for comments label Aug 6, 2018
@MichaelMure MichaelMure added the area/cli Relates to the CLI label Aug 23, 2018
@jlegeny
Copy link

jlegeny commented Aug 28, 2018

I'd like to suggest some additional commands for actions that do not seem currently possible:

  • git bug status to see what bugs were added since the latest push
  • git bug reset to undo changes to a bug
  • git bug remove to delete a bug

My main point is that it is important to be able to modify the state in all possible ways before it is pushed to the remote.

@MichaelMure
Copy link
Collaborator

@jlegeny that's a good point. Technically if possible to implement status and reset by comparing or copying the references in refs/bugs/* and refs/remotes/<remote>/bugs/*. That also mean that the actual status can be different if you use multiple remote.

@MichaelMure
Copy link
Collaborator

MichaelMure commented Sep 6, 2018 •
edited by adamslc
Loading

With the previous comments, I tried to summon my inner UX guy and devise a plan:

Current situation

  • git bug: show help

  • git bug ls: list bugs

  • git bug push [<remote>]: push to remote

  • git bug pull [<remote>]: pull from remote

  • git bug termui: launch the terminal UI

  • git bug webui [-p 1234]: launch the web UI

  • git bug new [-t "title"] [-m "message"]: new bug

  • git bug comment <id> [-m "message"]: add comment

  • git bug label <id> [-r] [<label>...]: add/remove labels

  • git bug open <id>: change status to OPEN

  • git bug close <id>: change status to CLOSE

Problems/questions

  • missing git bug title
  • should git bug run the termui instead of showing the help ?
  • merge open and close into a status command ?
  • new is not a verb
  • label has a different UX
  • can't have a select mechanism with the current label --> what is the id, what is a label ?
  • is it better to favor short commands or complete set of features for the CLI ? (e.g. git bug title to edit, or git bug title to show the current title and git bug title change to change it) ?

New shinny plan

As before

  • git bug push [<remote>]: push to remote
  • git bug pull [<remote>]: pull from remote
  • git bug termui: launch the terminal UI
  • git bug webui [-p 1234]: launch the web UI

Changed

  • git bug: list bugs
  • git bug comment [<id>]: show all comments
  • git bug comment add [<id>] [-m "message"]: add comment
  • git bug label [<id>]: show all labels
  • git bug label add [<id>] <label>...: add labels
  • git bug label rm [<id>] <label>...: remove labels

Removed

  • git bug new: renamed to add
  • git bug ls: removed in favor of git bug

Added

  • git bug add [-t "title"] [-m "message"]: new bug
  • git bug title [<id>]: show the title
  • git bug title edit [<id>]: edit the title
  • git bug diff [<id>] [<remote>]: show what bugs have been added/changed regarding the default or explicit remote. No select mechanism here, the is a filter.
  • git bug status [<id>]: show the current status
  • git bug status open [<id>]: change status to open
  • git bug status close [<id>]: change status to closed
  • git bug reset <id> [<remote>]: clear the changes of a bug to match the bug of a remote
  • git bug rm <id> [<remote>]: remove a bug locally or on a remote

select mechanism

  • git bug select <id>: select a bug for implicit editing later
  • using a command with an explicit id discard the selected id
  • automatic select with new/add ?
  • instead of an id, a filter could be used (e.g.: git select "UX refinement"), and it would work if only one bug match. Actually no, it's weird to craft a query that would only give one result
  • should display a summary of the selected bug when successfully selecting to avoid mistakes
  • there is still a potential conflict when a command has both an id and arbitrary args (e.g. git bug label add). That will require a test to see if the first arg could be a bug id or a prefix to a bug id. There is really unlikely case where it could be a problem though: git bug label add cafe when we have a bug with an id starting with cafe.

What do you all think ?

@j-f1
Copy link
Contributor

j-f1 commented Sep 6, 2018

How about git bug label and git bug unlabel?

@MichaelMure
Copy link
Collaborator

@j-f1 you would have no commands to see the label of a bug. Also, consistency and predictability are paramount for a good UX.

@MichaelMure
Copy link
Collaborator

The downside of this new approach is that the commands are quite long. git bug title edit is 18 characters without the new title itself nor a bug id/prefix.

This is mitigated by the command auto-completion and the termUI though. Another way would be to have a short alias to the git-bug binary. Another way would be to have a git bug shell command that would spawn a terminal where commands would be simply title edit and so on.

@MichaelMure
Copy link
Collaborator

Alright, I made the "safe" changes, as detailed above.

The missing parts are either completely new commands or things I'm unsure about. Please have a test and give me some feedback.

@adamslc
Copy link
Collaborator

adamslc commented Oct 6, 2018

What are your plans for a git bug config command? To start off the conversation, here is an incomplete list of things that might possibly need to be configured. Note that I'm not arguing that everything on this list should actually be implemented.

  • Default remote
  • Set of possible labels
  • Possibly move git bug bridge configure under here?
  • Default new bug and comment templates
  • Keybindings in termui
  • Author data specific to git bug. I'm not sure if this exists?

Also, I think that having connivance flags to update the config from other commands makes sense. In #62 I suggested using -d and --set-default in git bug push to get and set the default remote. I'm now convinced that those aren't the right flags to use (looks to much like delete), but I still think that this is important functionality. Perhaps mirroring git push and using -u and --set-upstream would makes sense.

@j-f1
Copy link
Contributor

j-f1 commented Oct 7, 2018

Why not use the regular git config command and name the settings git-bug.foo?

@adamslc
Copy link
Collaborator

adamslc commented Oct 7, 2018

For some settings, I think that makes a lot of sense, but not all of these configuration options can be stored in a local config file. In particular, modifying the set of allowed labels seems like it needs to be more closely integrated with git bug.

@MichaelMure
Copy link
Collaborator

Let's move the config discussion here: #63

@MichaelMure
Copy link
Collaborator

I move the missing part in separate discussion, I guess we can consider the matter here resolved.

#64
#65
#66

@golangcibot golangcibot mentioned this issue Jul 9, 2019
Merged
5 tasks
cheshirekow added a commit to cheshirekow/git-bug that referenced this issue Nov 12, 2019
@cheshirekow
Checkpoint git-bug#2: Working mostly complete export
0eb8db0
cheshirekow added a commit to cheshirekow/git-bug that referenced this issue Dec 5, 2019
@cheshirekow
codereview git-bug#2: some cleanup, correct use of nothing-events
056e90c 
* return error, don't panic
* skipping status export is an error
* use switch in config.go
* move PromptPassword to input
* move client construction into getIdentityClient
* use non-pointer context throughout client since it is an interface
* remove some TODOs
* don't emit multiple nothing-events, just one per bug only if nothing
  happened.
* rename EditBody to EditCreateComment
* add configuration notes about additional values
* sore bug id map in a dictionary in the config
cheshirekow added a commit to cheshirekow/git-bug that referenced this issue Dec 5, 2019
@cheshirekow
codereview git-bug#2: some cleanup, correct use of nothing-events
0ef9b80 
* return error, don't panic
* skipping status export is an error
* use switch in config.go
* move PromptPassword to input
* move client construction into getIdentityClient
* use non-pointer context throughout client since it is an interface
* remove some TODOs
* don't emit multiple nothing-events, just one per bug only if nothing
  happened.
* rename EditBody to EditCreateComment
* add configuration notes about additional values
* store bug id map in a dictionary in the config
* some fixes from testing
cheshirekow added a commit to cheshirekow/git-bug that referenced this issue Dec 18, 2019
@cheshirekow
codereview git-bug#2: some cleanup, correct use of nothing-events
cd88957 
* return error, don't panic
* skipping status export is an error
* use switch in config.go
* move PromptPassword to input
* move client construction into getIdentityClient
* use non-pointer context throughout client since it is an interface
* remove some TODOs
* don't emit multiple nothing-events, just one per bug only if nothing
  happened.
* rename EditBody to EditCreateComment
* add configuration notes about additional values
* store bug id map in a dictionary in the config
* some fixes from testing
MichaelMure pushed a commit that referenced this issue Feb 5, 2021
@claudioantonio
Merge pull request #2 from claudioantonio/webui_544
e68e930 
Commit for #544
@GlancingMind GlancingMind mentioned this issue Mar 20, 2021
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area/cli Relates to the CLI RFC Request for comments
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@afranke @ermik @MichaelMure @jlegeny @adamslc @j-f1