`bug add` should not open an editor if `-m` is provided

Labels: area/cli kind/feature priority/backlog triage/accepted

Yongwen Zhuang (zYeoman) opened

I think it's better to change the behavior to the same as git commit -m.

Michael Muré (MichaelMure) commented

Can you explain what you feel is wrong in the behavior ?

Yongwen Zhuang (zYeoman) commented (edited)

git bug add -t and git bug add -m behave almost the same: add a line and open an editor. The only difference is that git bug add -t add to first line and git bug add -m add to third line.

In my opinion, git bug add -m should directly add the message, without opening an editor, just like what git commit -m does.

PS: git commit -m

-m <msg>, --message=<msg> Use the given <msg> as the commit message. If multiple -m options are given, their values are concatenated as separate paragraphs.

Michael Muré (MichaelMure) commented

git bug add need both a title and a message to create a new bug. I think what you are looking for is git bug -t "my title" -m "my message".

Yongwen Zhuang (zYeoman) commented

Maybe we need a quickly add option to add just one line message (only the title) without editor. Anyway, it's up to you.

I'll try git bug -t "my title" -m "my message"

Michael Muré (MichaelMure) commented

Hmm, that's a good point. There is no way currently to file a bug with a title but no message without opening the editor.

Michael Muré (MichaelMure) changed the title from `bug add` should not open an editor if `-m` is provided to no CLI way to file a bug with a title but no message without opening the editor

Michael Muré (MichaelMure) added label enhancement

Michael Muré (MichaelMure) added label area/cli

Michael Muré (MichaelMure) added label Easy pick

Michael Muré (MichaelMure) changed the title from no CLI way to file a bug with a title but no message without opening the editor to `bug new` should accept a title and no message without opening a text editor

github-actions (github-actions) commented

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

sudoforge removed label Easy pick

sudoforge removed label enhancement

sudoforge removed label lifecycle/stale

sudoforge added label kind/feature

sudoforge added label priority/awaiting-more-evidence

sudoforge added label triage/needs-information

sudoforge commented (edited)

I'm in favor of refactoring this such that "titles" are not a first class citizen, and instead are simply the first line of the message. This is similar to how git handles the "subject" line of the commit message.

In other words, what I'm thinking is that we remove -t | --title altogether, and git bug add would open an editor, whereas git bug add -m "my message here" would set the content, and because it's only a single line, that would also be what we show for the "title".

This is largely how git-bug behaves today, however, -m still opens an editor.

sudoforge removed label priority/awaiting-more-evidence

sudoforge added label priority/backlog

sudoforge changed the title from `bug new` should accept a title and no message without opening a text editor to `bug add` should not open an editor if `-m` is provided

sudoforge removed label triage/needs-information

sudoforge added label triage/accepted