Re: [PATCH] git-filter-branch could be confused by similar names

Dmitry Potapov [off-list ref] writes:

On Thu, Jan 03, 2008 at 01:27:27PM -0800, Junio C Hamano wrote:

quoted

... I had an
impression that we try to stick to a subset of BRE (namely, no
\{m,n\}, [::], [==], nor [..]).

I was not aware about this policy, and I am not aware about
existing any grep that does not grok the expressions I used
above. So, I thought they are commonly accepted, but I might
be wrong.

Well I might be wrong too, as I did not vet all the existing use
of grep in our code.  That's why I said I had "an impression".

Now I have ("git grep 'grep ' -- 'git-*.sh'"), and it seems to
be that we do stick to a narrow subset of BRE.

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

 * We do not use -E;

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

IOW, our scripts' use of grep is very 80'sh ;-)

I do not mind using things that are available in POSIX BRE, but
let's not rely on GNU extension that may cause issues to other
people.

Other things I noticed while looking at "t/*.sh":

 * t/t3600-rm.sh and t/5401-update-hooks.sh have unnecessary
   uses of egrep that can instead be grep;

 * t/t3800-mktag.sh uses egrep but I think it can be grep; also,
   I think the use of temporary file expect.pat is unnecessary.

 * t/t5510-fetch.sh does use '^[0-9a-f]\{40\} '.

 * t/t7001-mv.sh uses -E only to use '.+' when it can just as
   easily say '..*' instead.

 * t/t7600-merge.sh has two occurrences of (GNU extended) " \+"
   that should be "  *" for portability.  An alternative is to
   use grep -E and say " +" instead, but then the other plus
   sign on the same line needs to be quoted.

Other than the one in 5510 I consider them log hanging fruits
for janitors.