Re: How can I search git log with ceratin keyword but without the other keyword?

From: 孙世龙 sunshilong <sunshilong369@gmail.com>
Date: Jul 19, 2020, 05:28 UTC
Message-ID: <CAAvDm6aNN2kDh=SF6_K-v+cq0a94tcQ1AQ-Fpgs2mNo18FTFfQ@mail.gmail.com>
In-Reply-To: <xmqqlfjgbssl.fsf@gitster.c.googlers.com>

Hi,

Show 8 quoted lines

>Sorry, it is currently not in the area of interest for me to examine
>an extensive rewrite of the "grep" machinery for unknown benefit.
>The cost-benefit ratio does not look too great to just add "X && !Y"
>support to existing "X && Y" logic.  If we were seriously extending
>the machinery, I'd rather see us shooting for even more generic
>boolean expression support, not just "our --all-match currently
>requires all of the AND-ed terms to positively match, but lets make
>it possible to require some of these terms not to fire at all".

I see. Maybe, there is a workaround method to achieve this goal( i.e. X&&!Y) without rewriting the "grep" machinery. Is there some method(or command provided by git) that could get the comments of a certain commitment(e.g: first, second,... nth) other than getting the last several comments by "git log -n"? So if there is an answer to this question, we can achieve that goal by shell script and git commands.

My answer to this question is: git log -n 1 --skip certain_number

Is there some command that could better achieve this goal?

Thank you for your attention to this matter.

On Sun, Jul 19, 2020 at 2:07 AM Junio C Hamano <gitster@pobox.com> wrote:

Show 20 quoted lines

>
> 孙世龙 sunshilong <sunshilong369@gmail.com> writes:
>
> > Thank you for your detailed explanation.
> >
> >>There is not much room for the line-level "--not" operator to
> >>participate in this picture.
> > After I have carefully read your explanation again and again.
> > Maybe, I think there is a way to achieve this goal.
> > Please point out if there is something wrong.
>
> Sorry, it is currently not in the area of interest for me to examine
> an extensive rewrite of the "grep" machinery for unknown benefit.
> The cost-benefit ratio does not look too great to just add "X && !Y"
> support to existing "X && Y" logic.  If we were seriously extending
> the machinery, I'd rather see us shooting for even more generic
> boolean expression support, not just "our --all-match currently
> requires all of the AND-ed terms to positively match, but lets make
> it possible to require some of these terms not to fire at all".
>