From: Brandon Casey <redacted>
This adds fortran xfuncname and wordRegex patterns to the list of builtin
patterns. The intention is for the patterns to be appropriate for all
versions of fortran including 77, 90, 95. The patterns can be enabled by
adding the diff=fortran attribute to the .gitattributes file for the
desired file glob.
This also adds a new macro named iPATTERN which is just like the PATTERNS
macro except it sets the REG_ICASE flag so that case will be ignored.
The test code in t4018 and the docs were updated as appropriate.
Signed-off-by: Brandon Casey <redacted>
---
Documentation/gitattributes.txt | 2 ++
t/t4018-diff-funcname.sh | 2 +-
userdiff.c | 17 +++++++++++++++++
3 files changed, 20 insertions(+), 1 deletions(-)
@@ -477,6 +477,8 @@ patterns are available: - `csharp` suitable for source code in the C# language.+- `fortran` suitable for source code in the Fortran language.+ - `html` suitable for HTML/XHTML documents. - `java` suitable for source code in the Java language.
From: Brandon Casey <redacted>
Generally, trailing space is removed from the string matched by the
xfuncname patterns. The exception is when the matched string exceeds the
length of the fixed-size buffer that it will be copied in to. But, a
string that exceeds the buffer can still contain trailing space in the
portion of the string that will be copied into the buffer. So, simplify
this code slightly, and just perform the trailing space removal always.
Signed-off-by: Brandon Casey <redacted>
---
xdiff-interface.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
From: Brandon Casey <redacted>
Previously (e3bf5e43), a test was added to test whether the builtin
xfuncname regular expressions could be compiled without error by regcomp.
Let's do the same for the word_regex patterns. This should help catch any
cross-platform incompatibilities that exist between the pattern creator's
system and the various platforms that the test suite is commonly run on.
Signed-off-by: Brandon Casey <redacted>
---
t/t4018-diff-funcname.sh | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
Makes sense, and closes a leak. But I wonder why word_regex is a pointer
to malloc'd memory at all? Couldn't it just be an actual regex_t inside
the diff_words struct, and we regcomp and regfree it?
I guess maybe having it be NULL is useful. You could check
diff_words->o->word_regex, but I suppose that would mean carrying an
extra variable around through the callchain.
-Peff
From: Jeff King <hidden> Date: 2016-06-15 22:49:31
On Thu, Sep 09, 2010 at 02:02:46PM -0500, Brandon Casey wrote:
From: Brandon Casey <redacted>
Generally, trailing space is removed from the string matched by the
xfuncname patterns. The exception is when the matched string exceeds the
length of the fixed-size buffer that it will be copied in to. But, a
string that exceeds the buffer can still contain trailing space in the
portion of the string that will be copied into the buffer. So, simplify
this code slightly, and just perform the trailing space removal always.
Hrm. So we are cutting off trailing space that might have been
non-trailing space in their original string? It is hard to argue that is
much worse than truncating the original string in the first place. But I
really wonder whether we should be silently truncating anything, and not
just dying or somehow handling this better?
If I understand what is going on (and I'm not sure that I do), are we
silently producing bogus word-diffs in the face of really long lines?
-Peff
From: Jeff King <hidden> Date: 2016-06-15 22:49:31
On Thu, Sep 09, 2010 at 02:02:47PM -0500, Brandon Casey wrote:
From: Brandon Casey <redacted>
Previously (e3bf5e43), a test was added to test whether the builtin
xfuncname regular expressions could be compiled without error by regcomp.
Let's do the same for the word_regex patterns. This should help catch any
cross-platform incompatibilities that exist between the pattern creator's
system and the various platforms that the test suite is commonly run on.
Definitely something we should be doing, but one nit:
From: Jeff King <hidden> Date: 2016-06-15 22:49:31
On Thu, Sep 09, 2010 at 02:02:48PM -0500, Brandon Casey wrote:
This adds fortran xfuncname and wordRegex patterns to the list of builtin
patterns. The intention is for the patterns to be appropriate for all
versions of fortran including 77, 90, 95. The patterns can be enabled by
adding the diff=fortran attribute to the .gitattributes file for the
desired file glob.
The rest of your series looks reasonable, modulo the comments I posted
to individual patches. But I won't torture my eyes by trying to actually
see how well this matches fortran code, and just assume this is a good
change. :)
This also adds a new macro named iPATTERN which is just like the PATTERNS
macro except it sets the REG_ICASE flag so that case will be ignored.
Style nit: please keep macros all uppercase.
-Peff
On Thu, Sep 09, 2010 at 02:02:46PM -0500, Brandon Casey wrote:
quoted
From: Brandon Casey <redacted>
Generally, trailing space is removed from the string matched by the
xfuncname patterns. The exception is when the matched string exceeds the
length of the fixed-size buffer that it will be copied in to. But, a
string that exceeds the buffer can still contain trailing space in the
portion of the string that will be copied into the buffer. So, simplify
this code slightly, and just perform the trailing space removal always.
Hrm. So we are cutting off trailing space that might have been
non-trailing space in their original string? It is hard to argue that is
much worse than truncating the original string in the first place. But I
really wonder whether we should be silently truncating anything, and not
just dying or somehow handling this better?
If I understand what is going on (and I'm not sure that I do), are we
silently producing bogus word-diffs in the face of really long lines?
I don't think this function is used to do the word-diffs. Unless I'm
missing something, ff_regexp is only used to do the funcname matching to
produce the hunk header string. An 80-byte buffer is used to hold
that string. So, the trimming is performed on what is effectively a
comment.
-Brandon
From: Jeff King <hidden> Date: 2016-06-15 22:49:31
On Thu, Sep 09, 2010 at 02:33:15PM -0500, Brandon Casey wrote:
On 09/09/2010 02:21 PM, Jeff King wrote:
quoted
On Thu, Sep 09, 2010 at 02:02:46PM -0500, Brandon Casey wrote:
quoted
From: Brandon Casey <redacted>
Generally, trailing space is removed from the string matched by the
xfuncname patterns. The exception is when the matched string exceeds the
length of the fixed-size buffer that it will be copied in to. But, a
string that exceeds the buffer can still contain trailing space in the
portion of the string that will be copied into the buffer. So, simplify
this code slightly, and just perform the trailing space removal always.
Hrm. So we are cutting off trailing space that might have been
non-trailing space in their original string? It is hard to argue that is
much worse than truncating the original string in the first place. But I
really wonder whether we should be silently truncating anything, and not
just dying or somehow handling this better?
If I understand what is going on (and I'm not sure that I do), are we
silently producing bogus word-diffs in the face of really long lines?
I don't think this function is used to do the word-diffs. Unless I'm
missing something, ff_regexp is only used to do the funcname matching to
produce the hunk header string. An 80-byte buffer is used to hold
that string. So, the trimming is performed on what is effectively a
comment.
Ah, OK, that makes a lot more sense. Then yeah, we should always be
trimming trailing whitespace from the result, so your patch is good.
-Peff
On Thu, Sep 09, 2010 at 02:02:47PM -0500, Brandon Casey wrote:
quoted
From: Brandon Casey <redacted>
Previously (e3bf5e43), a test was added to test whether the builtin
xfuncname regular expressions could be compiled without error by regcomp.
Let's do the same for the word_regex patterns. This should help catch any
cross-platform incompatibilities that exist between the pattern creator's
system and the various platforms that the test suite is commonly run on.
Definitely something we should be doing, but one nit:
On Thu, Sep 09, 2010 at 02:02:48PM -0500, Brandon Casey wrote:
quoted
This adds fortran xfuncname and wordRegex patterns to the list of builtin
patterns. The intention is for the patterns to be appropriate for all
versions of fortran including 77, 90, 95. The patterns can be enabled by
adding the diff=fortran attribute to the .gitattributes file for the
desired file glob.
The rest of your series looks reasonable, modulo the comments I posted
to individual patches. But I won't torture my eyes by trying to actually
see how well this matches fortran code, and just assume this is a good
change. :)
I can send you some. :)
quoted
This also adds a new macro named iPATTERN which is just like the PATTERNS
macro except it sets the REG_ICASE flag so that case will be ignored.
Style nit: please keep macros all uppercase.
Ah, yeah, I guess you're right.
IPATTERN
Thanks,
-Brandon
From: Brandon Casey <redacted>
This adds fortran xfuncname and wordRegex patterns to the list of builtin
patterns. The intention is for the patterns to be appropriate for all
versions of fortran including 77, 90, 95. The patterns can be enabled by
adding the diff=fortran attribute to the .gitattributes file for the
desired file glob.
This also adds a new macro named IPATTERN which is just like the PATTERNS
macro except it sets the REG_ICASE flag so that case will be ignored.
The test code in t4018 and the docs were updated as appropriate.
Signed-off-by: Brandon Casey <redacted>
---
This version renames the iPATTERN macro to the all uppercase IPATTERN, and
is a replacement for the version in pu.
Documentation/gitattributes.txt | 2 ++
t/t4018-diff-funcname.sh | 2 +-
userdiff.c | 17 +++++++++++++++++
3 files changed, 20 insertions(+), 1 deletions(-)
@@ -477,6 +477,8 @@ patterns are available: - `csharp` suitable for source code in the C# language.+- `fortran` suitable for source code in the Fortran language.+ - `html` suitable for HTML/XHTML documents. - `java` suitable for source code in the Java language.
FWIW (but don't think you need to change 'em) I'd do these as
(untested):
test_expect_success "builtin $p wordRegex pattern compiles" '
git diff --no-index --word-diff >out 2>err &&
# Or whatever out should be..
! test -s out &&
grep fatal err
'
It's much easier to debug tests that use intermediate files with
--immediate --debug when they break, because you can just check out
what out and err contain. You can't do that if the output was
forgotten in some pipe.
Maybe I should add a bit into t/README about this ...