All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Amisha Chhajed <amishhhaaaa@gmail.com>
Cc: git@vger.kernel.org,  avarab@gmail.com,  peff@peff.net,
	 stolee@gmail.com
Subject: Re: [PATCH v4 1/1] help: cleanup the contruction of keys_uniq
Date: Mon, 02 Mar 2026 08:04:02 -0800	[thread overview]
Message-ID: <xmqqwlzu43rh.fsf@gitster.g> (raw)
In-Reply-To: <20260228104654.80831-2-amishhhaaaa@gmail.com> (Amisha Chhajed's message of "Sat, 28 Feb 2026 16:16:54 +0530")

Amisha Chhajed <amishhhaaaa@gmail.com> writes:

> diff --git a/t/t0012-help.sh b/t/t0012-help.sh
> index d3a0967e9d..03104b3bf4 100755
> --- a/t/t0012-help.sh
> +++ b/t/t0012-help.sh
> @@ -141,20 +141,20 @@ test_expect_success 'git help -c' '
>  
>  	'\''git help config'\'' for more information
>  	EOF
> -	grep -v -E \
> -		-e "^[^.]+\.[^.]+$" \
> -		-e "^[^.]+\.[^.]+\.[^.]+$" \
> +	sed \
> +		-e "/^[^.]*\.[^.]*$/d" \
> +		-e "/^[^.]*\.[^.]*\.[^.]*$/d" \
>  		help.output >actual &&

We used to require at least one non-dot byte between each dot in the
original, but now we do not.  Is this change in semantics intended?

You could fix it with "sed -E" and keeping the ERE in the original,
I guess?

It was in a distant past when I tried benchmarking them for the last
time, but I recall "sed" was a lot slower than "grep" on a "match
and print" job that "grep" could be an alternative.  So I am not
sure what the point of the change in this hunk is.

>  	test_cmp expect actual
>  '
>  
>  test_expect_success 'git help --config-for-completion' '
>  	git help -c >human &&
> -	grep -E \
> -	     -e "^[^.]+\.[^.]+$" \
> -	     -e "^[^.]+\.[^.]+\.[^.]+$" human |
> -	     sed -e "s/\*.*//" -e "s/<.*//" |
> -	     sort -u >human.munged &&
> +	sed -n \
> +	     -e "/^[^.]*\.[^.]*$/p" \
> +	     -e "/^[^.]*\.[^.]*\.[^.]*$/p" human |
> +	sed -e "s/\*.*//" -e "s/<.*//" |

Ditto.

>  test_expect_success 'git help --config-sections-for-completion' '
>  	git help -c >human &&
> -	grep -E \
> -	     -e "^[^.]+\.[^.]+$" \
> -	     -e "^[^.]+\.[^.]+\.[^.]+$" human |
> -	     sed -e "s/\..*//" |
> -	     sort -u >human.munged &&
> +	sed -n \
> +	     -e "/^[^.]*\.[^.]*$/p" \
> +	     -e "/^[^.]*\.[^.]*\.[^.]*$/p" human |
> +	sed -e "s/\..*//" |

Ditto.

Just like piping "grep" output to "sed" is an anti-pattern, piping
"sed" output to an invocation of "sed" is often an anti-pattern.

Perhaps something like this would replace the original "grep | sed"
pipeline?

	sed -E -e "
		/^[^.]+\.[^.]+$/b out
		/^[^.]+\.[^.]+\.[^.]+$/b out
		d
		: out
		s/\..*//
	" human |
	sort -u



  reply	other threads:[~2026-03-02 16:04 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-12  4:10 [PATCH 0/2] clean leftover calls to string_list_remove_duplicates Amisha Chhajed
2026-02-12  4:10 ` [PATCH 1/2] sparse-checkout: use string_list_sort_u Amisha Chhajed
2026-02-12 19:30   ` Junio C Hamano
2026-02-12  4:10 ` [PATCH 2/2] help: ensure &keys_uniq follows sort -u Amisha Chhajed
2026-02-12 19:58   ` Junio C Hamano
2026-02-12 21:29     ` Amisha Chhajed
2026-02-12 21:37       ` Junio C Hamano
2026-02-13  3:37 ` [PATCH v2 1/2] sparse-checkout: use string_list_sort_u Amisha Chhajed
2026-02-13  3:37   ` [PATCH v2 2/2] help: cleanup the contruction of keys_uniq Amisha Chhajed
2026-02-13  4:30     ` Junio C Hamano
2026-02-13  5:02       ` Eric Sunshine
2026-02-13 16:57         ` Junio C Hamano
2026-02-21 16:28       ` Amisha Chhajed
2026-02-21 16:23 ` [PATCH v3 1/2] sparse-checkout: use string_list_sort_u Amisha Chhajed
2026-02-21 16:23   ` [PATCH v3 2/2] help: cleanup the contruction of keys_uniq Amisha Chhajed
2026-02-22  5:05     ` Junio C Hamano
2026-02-22  9:47       ` Amisha Chhajed
2026-02-26 16:45         ` Junio C Hamano
2026-02-28 10:51           ` Amisha Chhajed
2026-03-02 16:06             ` Junio C Hamano
2026-02-22  2:44   ` [PATCH v3 1/2] sparse-checkout: use string_list_sort_u Junio C Hamano
2026-02-28 10:46 ` [PATCH v4 0/1] Make keys_uniq stop depending on sort of keys_uniq Amisha Chhajed
2026-02-28 10:46   ` [PATCH v4 1/1] help: cleanup the contruction " Amisha Chhajed
2026-03-02 16:04     ` Junio C Hamano [this message]
2026-03-11 19:48       ` Amisha Chhajed
2026-03-11 21:11         ` Junio C Hamano
2026-03-11 21:39           ` Eric Sunshine
2026-03-11 21:50             ` Junio C Hamano
2026-03-11 21:54               ` Eric Sunshine
2026-03-11 19:24 ` [PATCH v5] " Amisha Chhajed
2026-03-11 19:46   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqwlzu43rh.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=amishhhaaaa@gmail.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=stolee@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.