Jeff King p...@peff.net writes:
Here is the patch I wrote, for reference (I also think breaking the
matches function into a series of conditionals, as you showed, is way
more readable):
OK, while reviewing the today's issue of What's cooking and making
topics graduate to 'master', I got
On Thu, Sep 11, 2014 at 04:35:33PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Here is the patch I wrote, for reference (I also think breaking the
matches function into a series of conditionals, as you showed, is way
more readable):
OK, while reviewing the today's
Jeff King p...@peff.net writes:
I just used
#define CONFIG_REGEX_NONE ((void *)1)
as my magic sentinel value, both for the string and compiled regex
versions. Adding a bit to the store struct is a lot less disgusting and
error-prone. So I won't share mine here. :)
Actually, I wrote
On Mon, Aug 18, 2014 at 11:03:51PM -0700, Junio C Hamano wrote:
We already have some code paths that use ((void *)1) as a special
pointer value, so in that sense I would say it is not the end of the
world if you added a new one.
No, but if you use it to replace the regexp, you end up having
Currently if we have a config file like,
[foo]
baz
bar =
and we try something like, git config --add foo.baz roll, Git will
segfault. Moreover, for git config --add foo.bar roll, it will
overwrite the original value instead of appending after the existing
empty value.
The problem
Tanay Abhra tanay...@gmail.com writes:
Currently if we have a config file like,
[foo]
baz
bar =
and we try something like, git config --add foo.baz roll, Git will
segfault. Moreover, for git config --add foo.bar roll, it will
overwrite the original value instead of
Tanay Abhra tanay...@gmail.com writes:
Currently if we have a config file like,
[foo]
baz
bar =
and we try something like, git config --add foo.baz roll, Git will
segfault.
Thanks; this is a good find.
This is a tangent, but people please stop starting their sentence
with
On Mon, Aug 18, 2014 at 11:18:52AM -0700, Junio C Hamano wrote:
Are we sure that a^, which cannot be true for any string, will not
be caught by anybody's regcomp() as an error? I know regcomp()
accepts the expression and regexec() fails to match with GNU libc,
but that is not the whole of
8 matches
Mail list logo
