In both termui and on the command line, I can search for certain labels, but I can't search for bugs that don't have the label. eg:

    git bug  ls -l foo  # lists all bugs with label "foo"

It would be nice if there was an inverse label search. For example:

    git bug  ls -L foo  # lists all bugs that don't have label "foo"

this would be useful for many things.

I like this idea.

Now, due to the way things are done internally and by consistency, this feature also needs to exist in the query language. This query language is heavily inspired by the Github one. In this document they mention that you can prefix a term with a - to invert it's meaning.

So with you example, the plain-text query command would be git bug ls -label:foo. Problem is, this definitely looks like a command line flags, right ? That will confuse the CLI parser and potentially users as well. Maybe we could use ~ instead (used as "not" in logic notation)? Not sure that's less confusing though, as it looks very similar. Any better idea ?

Using the capital letter for the shorthand to invert the filter would works great though. For the long flags, maybe we can prefix them with not- ? So we would have --not-label foo or --not-status open.

Thoughts ?

Yup, I'm not married to the syntax, so "gut bug ls ~label:foo" is fine with me.

You may also want to consider how find does it, they use a bang (aka exclamation mark) there, eg:

 find /etc ! -type f

For the the long options --not-label is totally fine.

Michael Muré (MichaelMure) added label enhancement 6 years ago

Michael Muré (MichaelMure) added label Easy pick 6 years ago

I didn't realize this until recently, but searches for multiple labels seem to be doing a logical OR between the various labels, ie:

git bug ls -l foo1 -l foo2  # returns bugs that are labeled foo1 OR foo2

I was under the assumption that searching for multiple labels would filter the result set even further down.

Was this a deliberate choice?

The reason I ask is that I have some code written to implement an inverse label search. It works properly when given a single label, but the results are somewhat broken at the moment when given multiple labels. I wanted to make sure it was doing the right thing when given multiple labels.

Hmm that's a good point. I'd say that both AND and OR could be useful, but at least github favor the AND. Let's do the same !

• use AND to combine multiple label query

Btw, if you want to review the query language in general and suggest improvements, you are very much welcome !

Looking to Github, the behavior seems to be that searching for multiple labels joins them with AND, and searching for multiple inverse labels joins them with OR.

For example, given the following 3 issues for a given project:

issue name  label(s)
----------- -----
foo         foo
bar         bar
foobar      foo,bar

A search for label:foo label:bar returns ticket foobar only (AND), as opposed to all 3 tickets (OR) which is currently the behavior with git-bug.

A search for -label:foo -label:bar returns no tickets (OR). If it were AND, it would return tickets foo and bar and exclude ticket foobar.

So yeah, I agree with using the Github behavior as a reference.

but I noticed that git bug termuiis hanging in master, so I can't test it in the terminal ui. Is this is a known issue?

Never mind, seems to be a issue local to my setup.

but I noticed that git bug termuiis hanging in master, so I can't test it in the terminal ui. Is this is a known issue?

Never mind, seems to be a issue local to my setup.

This turned out to be related to #387 which has just been fixed (in the FreeBSD ports version), and I'm able to build from source with the same patch, so I'll pick up where I left off and continue to work on this feature.

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

sudoforge removed label Easy pick 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 10 months ago

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

sudoforge removed label lifecycle/dormant 7 months ago