git branch: multiple --merged and --no-merged options?

I find myself frequently running commands like this

  $ comm -12 <(git branch --no-merged master) <(git branch --merged next)

when checking for graduation candidates. Of course I first tried

  $ git branch --no-merged master --merged next

but this is equivalent to

  $ git branch --merged next


Isn't this query common enough to have a nicer interface? What do other
people use?

On Fri, Mar 15, 2013 at 02:38:12PM -0500, Jed Brown wrote:

I find myself frequently running commands like this

  $ comm -12 <(git branch --no-merged master) <(git branch --merged next)

That's a reasonable thing to want to do.

when checking for graduation candidates. Of course I first tried

  $ git branch --no-merged master --merged next

Yeah, sadly that does not work, as we use the same slot for the flag and
store only one of the two (and we also allow only one "--merged" head,
even though you could in theory want to know "merged to X, or merged to
Y"). I do not think there is a reason we could handle both. I think we
could even do it with a single traversal, but even with two traversals,
doing both in-process will be faster (because we only have to pull the
commits from disk once).

So I think it is something that ought to work, but it will need some
code written. Patches welcome. ;)

-Peff

Jeff King [off-list ref] writes:

On Fri, Mar 15, 2013 at 02:38:12PM -0500, Jed Brown wrote:

quoted

  $ git branch --no-merged master --merged next

Yeah, sadly that does not work, as we use the same slot for the flag and
store only one of the two (and we also allow only one "--merged" head,
even though you could in theory want to know "merged to X, or merged to
Y").

Hmm, I would have said conjunction (AND) was more natural than
disjunction (OR). If we add support for multiple '--merged' and
'--no-merged', do we expect to eventually have a full query grammar?

On Fri, Mar 22, 2013 at 09:46:42PM -0500, Jed Brown wrote:

quoted

On Fri, Mar 15, 2013 at 02:38:12PM -0500, Jed Brown wrote:

quoted

  $ git branch --no-merged master --merged next

Yeah, sadly that does not work, as we use the same slot for the flag and
store only one of the two (and we also allow only one "--merged" head,
even though you could in theory want to know "merged to X, or merged to
Y").

Hmm, I would have said conjunction (AND) was more natural than
disjunction (OR). If we add support for multiple '--merged' and
'--no-merged', do we expect to eventually have a full query grammar?

Yeah, you might want either. I was just thinking along the lines of the
existing --contains and --points-at (which only tag, not branch, knows
about), both of which OR multiple items. I think you'd want to flesh out
some use cases before deciding.

-Peff