For consistency, I think the ls command should be list and the rm command (for bridges) should be remove. This is consitent with create, comment etc..

Hmm, I'm not sure what you mean. Unless I'm missing something, git-bug always use the short ls or rm.

It's certainly possible to add alias for the full letter version though.

Yes cobra support aliases we can certainly support having the full letter and abbreviated versions for action commands like remove, list etc ... https://github.com/spf13/cobra/blob/master/command.go#L44-L45

The opposite argument could be made by saying that adding confusion with each time two commands doing the same thing require a good reason.

On Mon, Oct 28, 2019 at 11:53:23AM -0700, Michael Muré wrote:

The opposite argument could be made by saying that adding confusion with each time two commands doing the same thing require a good reason.

A good reason to keep "ls" is "backward compatibility" while a good reason to have "list"/"remove" is "consistency with other git commands" (think git worktree list, git worktree remove, git remote remove)

For reference, it is git remote remove and git notes remove. I am not aware of a core subcommand that has an explicit list action, neither with ls nor with list. The subcommands I can think of that have a list action are all done when there is no explicit action (git branch, git remote…).

Hi, from my user's perspective, I can just add a statement for the UX part.

Everytime I ask "git bug list", it responds with "did you mean ls?"... Git has a lot of real words as commands. I would vote for non abbreviated commands.

One thing about this is that I've been considering disconnecting git-bug from the main git command (that is, it would not be a porcelain command anymore), partially because of the git's author complaint about using the "bug" namespace and partially because the commands now can be quite long (git bug bridge pull for example could be changed to, say, gb bridge pull).

In this case, the argument of coherency with git is a bit moot.

gb bridge pull

gub would be fun (Git-BUg sharada, and reverse of bug) bug would also be friendly :)

In this case, the argument of coherency with git is a bit moot.

Not really. People still expect some consistency across tools, especially if they are used in the same context. Look at Unix command line utilities all using -v for verbose (and think of how infuriating it is when someone decides that it stands for --version) or other similar behaviours. If gub (I like that one) and git both use e.g. remove, that’s one less thing I have to keep reminding me of.

the git's author complaint about using the "bug" namespace

Is that really a big topic? IMHO "bug" is just an alias, whose name I can adjust to my favor. That could also be "git issue" or anything else...

See this thread when I first released git-bug: https://marc.info/?l=git&m=153454720614705&w=2

This bot triages untriaged issues and PRs according to the following rules:

• After 90 days of inactivity, the lifecycle/stale label is applied
• After 30 days of inactivity since lifecycle/stale was applied, the issue is closed

To remove the stale status, you can:

• Remove the lifecycle/stale label
• Comment on this issue

github-actions (github-actions) added label lifecycle/stale 1 year ago

This bot triages issues in order to help the maintainers identify what needs attention, according to the following lifecycle rules:

• After 90 days of inactivity, lifecycle/stale is applied
• After 90 days of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied

This bot will not automatically close stale issues.

To remove the stale status, you can:

• Remove the stale label from this issue
• Comment on this issue
• Close this issue
• Offer to help out with triaging

To avoid automatic lifecycle management of this issue, add lifecycle/frozen.

github-actions (github-actions) added label lifecycle/rotten 11 months ago

github-actions (github-actions) removed label lifecycle/stale 11 months ago

sudoforge removed label lifecycle/dormant 7 months ago