Re:

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 17, 2015, 17:49 UTC
Message-ID: <xmqqh9nxerfv.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CACsJy8Be-kY49CxAJTx2R2XG-c_WeuU=yLFT8-XSoaDkTScPGg@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

Show 11 quoted lines

> On Wed, Aug 5, 2015 at 7:47 PM, Ivan Chernyavsky <camposer@yandex.ru> wrote:
>> Dear community,
>>
>> For some time I'm wondering why there's no "--grep" option to the
>> "git branch" command, which would request to print only branches
>> having specified string/regexp in their history.
>
> Probably because nobody is interested and steps up to do it. The lack
> of response to you mail is a sign. Maybe you can try make a patch? I
> imagine it would not be so different from current --contains code, but
> this time we need to look into commits, not just commit id.

That is a dangeous thought. I'd understand if it were internally two step process, i.e. (1) the first pass finds commits that hits the --grep criteria and then (2) the second pass does "--contains" for all the hits found in the first pass using existing code, but still, this operation is bound to dig all the way through the root of the history when asked to find something that does not exist.

Show 7 quoted lines

>> So for example:
>>
>>     $ git branch -r --grep=BUG12345
>>
>> should be roughly equivalent to following expression I'm using now for the same task:
>>
>>     $ for r in `git rev-list --grep=BUG12345 --remotes=origin`; do git branch -r --list --contains=$r 'origin/*'; done | sort -u

You should at least feed all --contains to a single invocation of "git branch". They are designed to be OR'ed together.