git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 5, 2008, 01:17 UTC
Message-ID
<7v4pdtgjf0.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<20080104155114.GS3373@dpotapov.dyndns.org>
Dmitry Potapov <dpotapov@gmail.com> writes:
Show 9 quoted lines
> On Thu, Jan 03, 2008 at 01:27:27PM -0800, Junio C Hamano wrote:
>> ... 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.

Previous: Johannes Schindelin
Message 18 of 18 in “git-filter-branch could be confused by similar names”
  1. git-filter-branch could be confused by similar namesDmitry Potapov, Dec 25, 2007
  2. Johannes SchindelinDec 29, 2007
  3. Dmitry PotapovDec 30, 2007
  4. Johannes SchindelinDec 30, 2007
  5. Dmitry PotapovDec 30, 2007
  6. Johannes SchindelinDec 30, 2007
  7. Dmitry PotapovDec 30, 2007
  8. git-filter-branch could be confused by similar namesDmitry Potapov, Dec 30, 2007
  9. Junio C HamanoJan 3, 2008
  10. Dmitry PotapovJan 4, 2008
  11. Junio C HamanoJan 4, 2008
  12. Johannes SchindelinJan 5, 2008
  13. 1/2 git-rev-parse --symbolic-full-nameJunio C Hamano, Jan 5, 2008
  14. 2/2 filter-branch: work correctly with ambiguous refnamesJunio C Hamano, Jan 5, 2008
  15. Johannes SchindelinJan 6, 2008
  16. Junio C HamanoJan 6, 2008
  17. Johannes SchindelinJan 6, 2008
  18. Junio C HamanoJan 5, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.