22.08.2015, 12:19, "Ivan Chernyavsky" :
> One thing I'm worried about is that git-branch already has option --all. So
> we'll get a semantics conflict with setup_revisions() ("all branches" vs "all
> refs"). This will have to be treated ca
22.08.2015, 01:39, "Junio C Hamano" :
> Ivan Chernyavsky writes:
>
>> Another problem is that builtin/branch.c currently does not use
>> setup_revisions(), so I'll have to hook it there as well.
>
> Heh, you say "problem" above, but I do n
17.08.2015, 20:49, "Junio C Hamano" :
> Duy Nguyen writes:
>
>> On Wed, Aug 5, 2015 at 7:47 PM, Ivan Chernyavsky
>> wrote:
>
> That is a dangeous thought. I'd understand if it were internally
> two step process, i.e. (1) the first pass finds co
15.08.2015, 12:19, "Duy Nguyen" :
>
> 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
Sorry for empty subject in the original mail, somehow I've deleted it and
didn't even notice.
05.08.2015, 20:05, "Junio C Hamano" :
> Junio C Hamano writes:
>
>> I think people do things like:
>>
>> git log --all --decorate --grep=...
>
> s/decorate/source/; sorry for the noise.
Thanks Ju
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.
So for example:
$ git branch -r --grep=BUG12345
should be roughly equivalent to following exp
6 matches
Mail list logo
