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

4 messages from 2013-03-15 to 2013-03-23. Participants: Jed Brown, Jeff King.
Thread: https://gitlist.dev/t/33191

## Jed Brown, 2013-03-15 19:38

Subject: git branch: multiple --merged and --no-merged options?
Message-ID: <87fvzwmp23.fsf@59A2.org>
URL: https://gitlist.dev/e/87fvzwmp23.fsf%4059A2.org

```
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?

```

## Jeff King, 2013-03-22 17:50

Subject: Re: git branch: multiple --merged and --no-merged options?
Message-ID: <20130322175034.GB29011@sigill.intra.peff.net>
URL: https://gitlist.dev/e/20130322175034.GB29011%40sigill.intra.peff.net
In-Reply-To: <87fvzwmp23.fsf@59A2.org>

```
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

```

## Jed Brown, 2013-03-23 02:46

Subject: Re: git branch: multiple --merged and --no-merged options?
Message-ID: <8738vmu92l.fsf@59A2.org>
URL: https://gitlist.dev/e/8738vmu92l.fsf%4059A2.org
In-Reply-To: <20130322175034.GB29011@sigill.intra.peff.net>

```
Jeff King <peff@peff.net> writes:

> On Fri, Mar 15, 2013 at 02:38:12PM -0500, Jed Brown wrote:
>>   $ 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?

```

## Jeff King, 2013-03-23 08:13

Subject: Re: git branch: multiple --merged and --no-merged options?
Message-ID: <20130323081333.GC29768@sigill.intra.peff.net>
URL: https://gitlist.dev/e/20130323081333.GC29768%40sigill.intra.peff.net
In-Reply-To: <8738vmu92l.fsf@59A2.org>

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

> > On Fri, Mar 15, 2013 at 02:38:12PM -0500, Jed Brown wrote:
> >>   $ 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

```