RFC "grep '...\{m,n\}"?

[Junio C Hamano <gitster@pobox.com>]

"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> writes:

> diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
> index 8197ed29a9ec..a31f7e0430e1 100755
> --- a/t/t3404-rebase-interactive.sh
> +++ b/t/t3404-rebase-interactive.sh
> @@ -1039,4 +1039,11 @@ test_expect_success 'short SHA-1 collide' '
>  	)
>  '
>  
> +test_expect_success 'respect core.abbrev' '
> +	git config core.abbrev 12 &&
> +	set_cat_todo_editor &&
> +	test_must_fail git rebase -i HEAD~4 >todo-list &&
> +	test 4 = $(grep -c "pick [0-9a-f]\{12,\}" todo-list)
> +'

Documentation/CodingGuidelines says

 - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
   [::], [==], or [..]) for portability.

   - We do not use \{m,n\};

   - We do not use -E;

   - We do not use ? or + (which are \{0,1\} and \{1,\}
     respectively in BRE) but that goes without saying as these
     are ERE elements not BRE (note that \? and \+ are not even part
     of BRE -- making them accessible from BRE is a GNU extension).

but I see we have multiple hits from "git grep 'grep .*\\{'" (all in
the t/ directory).  I wonder

 - if everybody's system is now OK with \{m,n\} these days, or

 - there are people who are grateful that we stayed away from using
   \{m,n\} but they are not running the tests because their system
   is too exotic to pass other parts of the test suite.

If the former, we may want to drop the \{m,n\} from the forbidden
list.