Hi, >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@xxxxxxxxx> wrote: > > 孙世龙 sunshilong <sunshilong369@xxxxxxxxx> 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". >
