Re: git log filtering

From: Jeff King <peff@peff.net>
Date: Feb 9, 2007, 13:22 UTC
Message-ID: <20070209132239.GA727@coredump.intra.peff.net>
In-Reply-To: <Pine.LNX.4.63.0702091410230.22628@wbgn013.biozentrum.uni-wuerzburg.de>

On Fri, Feb 09, 2007 at 02:13:18PM +0100, Johannes Schindelin wrote:

> The difference, of course, is that with the "other things", we either have 
> no alternative (if you do not have curl, you cannot use HTTP transport), 
> or we have workalikes (if you don't use openssl, the (possibly slower) 
> SHA1 replacements take effect).

I'm not a pcre expert, but I thought most of the additions to posix extended regular expressions were expressed through constructs that would otherwise be invalid patterns. For example, '(?i)' doesn't make any sense as a pattern. Thus you would only see different behavior when inputting nonsense. Of course, we're not currently using extended regexps, but that could be made the default without additional dependencies.

> We _used_ to rely on external "diff" and "merge", but have them as inbuilt 
> components, exactly to avoid "if you have a slightly differing setup, 
> git behaves differently".

But you're OK with "if you didn't built against curl, http transport just doesn't work." So what if there is a '--pcre' option and a corresponding config option? Thus you get the same results always, unless you use --pcre and it's not built, in which case git dies. That seems to be the moral equivalent of the curl situation.

At any rate, you didn't address my original point, which is _all_ of those options have drawbacks. I think the drawbacks of re-writing or re-packaging a regular expression library outweigh those of adding the dependency (or even having slightly irregular behavior).

-Peff