2010-04-02 04:12:15 +04:00
|
|
|
#include "cache.h"
|
2008-10-06 01:43:21 +04:00
|
|
|
#include "userdiff.h"
|
|
|
|
#include "attr.h"
|
|
|
|
|
|
|
|
static struct userdiff_driver *drivers;
|
|
|
|
static int ndrivers;
|
|
|
|
static int drivers_alloc;
|
|
|
|
|
2009-01-21 07:59:54 +03:00
|
|
|
#define PATTERNS(name, pattern, word_regex) \
|
2011-01-12 00:48:50 +03:00
|
|
|
{ name, NULL, -1, { pattern, REG_EXTENDED }, \
|
|
|
|
word_regex "|[^[:space:]]|[\xc0-\xff][\x80-\xbf]+" }
|
2010-09-10 20:18:14 +04:00
|
|
|
#define IPATTERN(name, pattern, word_regex) \
|
2011-01-12 00:48:50 +03:00
|
|
|
{ name, NULL, -1, { pattern, REG_EXTENDED | REG_ICASE }, \
|
|
|
|
word_regex "|[^[:space:]]|[\xc0-\xff][\x80-\xbf]+" }
|
2008-10-06 01:43:21 +04:00
|
|
|
static struct userdiff_driver builtin_drivers[] = {
|
2012-09-16 07:54:15 +04:00
|
|
|
IPATTERN("ada",
|
2014-02-03 15:33:16 +04:00
|
|
|
"!^(.*[ \t])?(is[ \t]+new|renames|is[ \t]+separate)([ \t].*)?$\n"
|
2012-09-16 07:54:15 +04:00
|
|
|
"!^[ \t]*with[ \t].*$\n"
|
|
|
|
"^[ \t]*((procedure|function)[ \t]+.*)$\n"
|
|
|
|
"^[ \t]*((package|protected|task)[ \t]+.*)$",
|
|
|
|
/* -- */
|
|
|
|
"[a-zA-Z][a-zA-Z0-9_]*"
|
2014-02-03 15:33:16 +04:00
|
|
|
"|[-+]?[0-9][0-9#_.aAbBcCdDeEfF]*([eE][+-]?[0-9_]+)?"
|
2012-09-16 07:54:15 +04:00
|
|
|
"|=>|\\.\\.|\\*\\*|:=|/=|>=|<=|<<|>>|<>"),
|
2010-09-10 20:18:14 +04:00
|
|
|
IPATTERN("fortran",
|
|
|
|
"!^([C*]|[ \t]*!)\n"
|
|
|
|
"!^[ \t]*MODULE[ \t]+PROCEDURE[ \t]\n"
|
|
|
|
"^[ \t]*((END[ \t]+)?(PROGRAM|MODULE|BLOCK[ \t]+DATA"
|
|
|
|
"|([^'\" \t]+[ \t]+)*(SUBROUTINE|FUNCTION))[ \t]+[A-Z].*)$",
|
|
|
|
/* -- */
|
|
|
|
"[a-zA-Z][a-zA-Z0-9_]*"
|
|
|
|
"|\\.([Ee][Qq]|[Nn][Ee]|[Gg][TtEe]|[Ll][TtEe]|[Tt][Rr][Uu][Ee]|[Ff][Aa][Ll][Ss][Ee]|[Aa][Nn][Dd]|[Oo][Rr]|[Nn]?[Ee][Qq][Vv]|[Nn][Oo][Tt])\\."
|
|
|
|
/* numbers and format statements like 2E14.4, or ES12.6, 9X.
|
|
|
|
* Don't worry about format statements without leading digits since
|
|
|
|
* they would have been matched above as a variable anyway. */
|
|
|
|
"|[-+]?[0-9.]+([AaIiDdEeFfLlTtXx][Ss]?[-+]?[0-9.]*)?(_[a-zA-Z0-9][a-zA-Z0-9_]*)?"
|
2011-01-12 00:48:50 +03:00
|
|
|
"|//|\\*\\*|::|[/<>=]="),
|
2015-07-21 16:22:46 +03:00
|
|
|
IPATTERN("fountain", "^((\\.[^.]|(int|ext|est|int\\.?/ext|i/e)[. ]).*)$",
|
|
|
|
"[^ \t-]+"),
|
2009-01-17 19:29:48 +03:00
|
|
|
PATTERNS("html", "^[ \t]*(<[Hh][1-6][ \t].*>.*)$",
|
2011-01-12 00:48:50 +03:00
|
|
|
"[^<>= \t]+"),
|
2009-01-17 19:29:48 +03:00
|
|
|
PATTERNS("java",
|
2008-10-06 01:43:21 +04:00
|
|
|
"!^[ \t]*(catch|do|for|if|instanceof|new|return|switch|throw|while)\n"
|
2009-06-17 18:26:06 +04:00
|
|
|
"^[ \t]*(([A-Za-z_][A-Za-z_0-9]*[ \t]+)+[A-Za-z_][A-Za-z_0-9]*[ \t]*\\([^;]*)$",
|
|
|
|
/* -- */
|
2009-01-17 19:29:48 +03:00
|
|
|
"[a-zA-Z_][a-zA-Z0-9_]*"
|
|
|
|
"|[-+0-9.e]+[fFlL]?|0[xXbB]?[0-9a-fA-F]+[lL]?"
|
|
|
|
"|[-+*/<>%&^|=!]="
|
2011-01-12 00:48:50 +03:00
|
|
|
"|--|\\+\\+|<<=?|>>>?=?|&&|\\|\\|"),
|
2011-11-16 00:15:03 +04:00
|
|
|
PATTERNS("matlab",
|
|
|
|
"^[[:space:]]*((classdef|function)[[:space:]].*)$|^%%[[:space:]].*$",
|
|
|
|
"[a-zA-Z_][a-zA-Z0-9_]*|[-+0-9.e]+|[=~<>]=|\\.[*/\\^']|\\|\\||&&"),
|
2009-01-17 19:29:48 +03:00
|
|
|
PATTERNS("objc",
|
2008-10-06 01:43:21 +04:00
|
|
|
/* Negate C statements that can look like functions */
|
|
|
|
"!^[ \t]*(do|for|if|else|return|switch|while)\n"
|
|
|
|
/* Objective-C methods */
|
|
|
|
"^[ \t]*([-+][ \t]*\\([ \t]*[A-Za-z_][A-Za-z_0-9* \t]*\\)[ \t]*[A-Za-z_].*)$\n"
|
|
|
|
/* C functions */
|
2009-06-17 18:26:06 +04:00
|
|
|
"^[ \t]*(([A-Za-z_][A-Za-z_0-9]*[ \t]+)+[A-Za-z_][A-Za-z_0-9]*[ \t]*\\([^;]*)$\n"
|
2008-10-06 01:43:21 +04:00
|
|
|
/* Objective-C class/protocol definitions */
|
2009-01-17 19:29:48 +03:00
|
|
|
"^(@(implementation|interface|protocol)[ \t].*)$",
|
|
|
|
/* -- */
|
|
|
|
"[a-zA-Z_][a-zA-Z0-9_]*"
|
|
|
|
"|[-+0-9.e]+[fFlL]?|0[xXbB]?[0-9a-fA-F]+[lL]?"
|
2011-01-12 00:48:50 +03:00
|
|
|
"|[-+*/<>%&^|=!]=|--|\\+\\+|<<=?|>>=?|&&|\\|\\||::|->"),
|
2009-01-17 19:29:48 +03:00
|
|
|
PATTERNS("pascal",
|
2011-01-11 11:53:59 +03:00
|
|
|
"^(((class[ \t]+)?(procedure|function)|constructor|destructor|interface|"
|
2008-10-06 01:43:21 +04:00
|
|
|
"implementation|initialization|finalization)[ \t]*.*)$"
|
|
|
|
"\n"
|
2009-01-17 19:29:48 +03:00
|
|
|
"^(.*=[ \t]*(class|record).*)$",
|
|
|
|
/* -- */
|
|
|
|
"[a-zA-Z_][a-zA-Z0-9_]*"
|
|
|
|
"|[-+0-9.e]+|0[xXbB]?[0-9a-fA-F]+"
|
2011-01-12 00:48:50 +03:00
|
|
|
"|<>|<=|>=|:=|\\.\\."),
|
2010-12-26 12:07:31 +03:00
|
|
|
PATTERNS("perl",
|
2011-05-21 23:38:26 +04:00
|
|
|
"^package .*\n"
|
|
|
|
"^sub [[:alnum:]_':]+[ \t]*"
|
|
|
|
"(\\([^)]*\\)[ \t]*)?" /* prototype */
|
|
|
|
/*
|
|
|
|
* Attributes. A regex can't count nested parentheses,
|
|
|
|
* so just slurp up whatever we see, taking care not
|
|
|
|
* to accept lines like "sub foo; # defined elsewhere".
|
|
|
|
*
|
|
|
|
* An attribute could contain a semicolon, but at that
|
|
|
|
* point it seems reasonable enough to give up.
|
|
|
|
*/
|
|
|
|
"(:[^;#]*)?"
|
|
|
|
"(\\{[ \t]*)?" /* brace can come here or on the next line */
|
|
|
|
"(#.*)?$\n" /* comment */
|
2011-05-22 21:29:32 +04:00
|
|
|
"^(BEGIN|END|INIT|CHECK|UNITCHECK|AUTOLOAD|DESTROY)[ \t]*"
|
2011-05-21 23:38:26 +04:00
|
|
|
"(\\{[ \t]*)?" /* brace can come here or on the next line */
|
|
|
|
"(#.*)?$\n"
|
2011-05-21 23:35:51 +04:00
|
|
|
"^=head[0-9] .*", /* POD */
|
2010-12-26 12:07:31 +03:00
|
|
|
/* -- */
|
|
|
|
"[[:alpha:]_'][[:alnum:]_']*"
|
|
|
|
"|0[xb]?[0-9a-fA-F_]*"
|
|
|
|
/* taking care not to interpret 3..5 as (3.)(.5) */
|
|
|
|
"|[0-9a-fA-F_]+(\\.[0-9a-fA-F_]+)?([eE][-+]?[0-9_]+)?"
|
|
|
|
"|=>|-[rwxoRWXOezsfdlpSugkbctTBMAC>]|~~|::"
|
|
|
|
"|&&=|\\|\\|=|//=|\\*\\*="
|
|
|
|
"|&&|\\|\\||//|\\+\\+|--|\\*\\*|\\.\\.\\.?"
|
|
|
|
"|[-+*/%.^&<>=!|]="
|
|
|
|
"|=~|!~"
|
2011-01-12 00:48:50 +03:00
|
|
|
"|<<|<>|<=>|>>"),
|
2010-05-23 22:05:40 +04:00
|
|
|
PATTERNS("php",
|
|
|
|
"^[\t ]*(((public|protected|private|static)[\t ]+)*function.*)$\n"
|
|
|
|
"^[\t ]*(class.*)$",
|
2009-01-17 19:29:48 +03:00
|
|
|
/* -- */
|
|
|
|
"[a-zA-Z_][a-zA-Z0-9_]*"
|
|
|
|
"|[-+0-9.e]+|0[xXbB]?[0-9a-fA-F]+"
|
2011-01-12 00:48:50 +03:00
|
|
|
"|[-+*/<>%&^|=!.]=|--|\\+\\+|<<=?|>>=?|===|&&|\\|\\||::|->"),
|
2009-01-17 19:29:48 +03:00
|
|
|
PATTERNS("python", "^[ \t]*((class|def)[ \t].*)$",
|
|
|
|
/* -- */
|
|
|
|
"[a-zA-Z_][a-zA-Z0-9_]*"
|
|
|
|
"|[-+0-9.e]+[jJlL]?|0[xX]?[0-9a-fA-F]+[lL]?"
|
2011-01-12 00:48:50 +03:00
|
|
|
"|[-+*/<>%&^|=!]=|//=?|<<=?|>>=?|\\*\\*=?"),
|
2009-01-17 19:29:48 +03:00
|
|
|
/* -- */
|
|
|
|
PATTERNS("ruby", "^[ \t]*((class|module|def)[ \t].*)$",
|
|
|
|
/* -- */
|
|
|
|
"(@|@@|\\$)?[a-zA-Z_][a-zA-Z0-9_]*"
|
|
|
|
"|[-+0-9.e]+|0[xXbB]?[0-9a-fA-F]+|\\?(\\\\C-)?(\\\\M-)?."
|
2011-01-12 00:48:50 +03:00
|
|
|
"|//=?|[-+*/<>%&^|=!]=|<<=?|>>=?|===|\\.{1,3}|::|[!=]~"),
|
2009-01-17 19:29:48 +03:00
|
|
|
PATTERNS("bibtex", "(@[a-zA-Z]{1,}[ \t]*\\{{0,1}[ \t]*[^ \t\"@',\\#}{~%]*).*$",
|
|
|
|
"[={}\"]|[^={}\" \t]+"),
|
|
|
|
PATTERNS("tex", "^(\\\\((sub)*section|chapter|part)\\*{0,1}\\{.*)$",
|
2011-01-12 00:48:50 +03:00
|
|
|
"\\\\[a-zA-Z@]+|\\\\.|[a-zA-Z0-9\x80-\xff]+"),
|
2009-01-17 19:29:48 +03:00
|
|
|
PATTERNS("cpp",
|
|
|
|
/* Jump targets or access declarations */
|
userdiff: have 'cpp' hunk header pattern catch more C++ anchor points
The hunk header pattern 'cpp' is intended for C and C++ source code, but
it is actually not particularly useful for the latter, and even misses
some use-cases for the former.
The parts of the pattern have the following flaws:
- The first part matches an identifier followed immediately by a colon
and arbitrary text and is intended to reject goto labels and C++
access specifiers (public, private, protected). But this pattern also
rejects C++ constructs, which look like this:
MyClass::MyClass()
MyClass::~MyClass()
MyClass::Item MyClass::Find(...
- The second part matches an identifier followed by a list of qualified
names (i.e. identifiers separated by the C++ scope operator '::')
separated by space or '*' followed by an opening parenthesis (with
space between the tokens). It matches function declarations like
struct item* get_head(...
int Outer::Inner::Func(...
Since the pattern requires at least two identifiers, GNU-style
function definitions are ignored:
void
func(...
Moreover, since the pattern does not allow punctuation other than '*',
the following C++ constructs are not recognized:
. template definitions:
template<class T> int func(T arg)
. functions returning references:
const string& get_message()
. functions returning templated types:
vector<int> foo()
. operator definitions:
Value operator+(Value l, Value r)
- The third part of the pattern finally matches compound definitions.
But it forgets about unions and namespaces, and also skips single-line
definitions
struct random_iterator_tag {};
because no semicolon can occur on the line.
Change the first pattern to require a colon at the end of the line
(except for trailing space and comments), so that it does not reject
constructor or destructor definitions.
Notice that all interesting anchor points begin with an identifier or
keyword. But since there is a large variety of syntactical constructs
after the first "word", the simplest is to require only this word and
accept everything else. Therefore, this boils down to a line that begins
with a letter or underscore (optionally preceded by the C++ scope
operator '::' to accept functions returning a type anchored at the
global namespace). Replace the second and third part by a single pattern
that picks such a line.
This has the following desirable consequence:
- All constructs mentioned above are recognized.
and the following likely desirable consequences:
- Definitions of global variables and typedefs are recognized:
int num_entries = 0;
extern const char* help_text;
typedef basic_string<wchar_t> wstring;
- Commonly used marco-ized boilerplate code is recognized:
BEGIN_MESSAGE_MAP(CCanvas,CWnd)
Q_DECLARE_METATYPE(MyStruct)
PATTERNS("tex",...)
(The last one is from this very patch.)
but also the following possibly undesirable consequence:
- When a label is not on a line by itself (except for a comment) it is
no longer rejected, but can appear as a hunk header if it occurs at
the beginning of a line:
next:;
IMO, the benefits of the change outweigh the (possible) regressions by a
large margin.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-22 01:07:22 +04:00
|
|
|
"!^[ \t]*[A-Za-z_][A-Za-z_0-9]*:[[:space:]]*($|/[/*])\n"
|
|
|
|
/* functions/methods, variables, and compounds at top level */
|
|
|
|
"^((::[[:space:]]*)?[A-Za-z_].*)$",
|
2009-01-17 19:29:48 +03:00
|
|
|
/* -- */
|
|
|
|
"[a-zA-Z_][a-zA-Z0-9_]*"
|
2014-03-22 01:07:14 +04:00
|
|
|
"|[-+0-9.e]+[fFlL]?|0[xXbB]?[0-9a-fA-F]+[lLuU]*"
|
2014-03-22 01:07:13 +04:00
|
|
|
"|[-+*/<>%&^|=!]=|--|\\+\\+|<<=?|>>=?|&&|\\|\\||::|->\\*?|\\.\\*"),
|
2010-08-16 21:01:02 +04:00
|
|
|
PATTERNS("csharp",
|
|
|
|
/* Keywords */
|
|
|
|
"!^[ \t]*(do|while|for|if|else|instanceof|new|return|switch|case|throw|catch|using)\n"
|
|
|
|
/* Methods and constructors */
|
|
|
|
"^[ \t]*(((static|public|internal|private|protected|new|virtual|sealed|override|unsafe)[ \t]+)*[][<>@.~_[:alnum:]]+[ \t]+[<>@._[:alnum:]]+[ \t]*\\(.*\\))[ \t]*$\n"
|
|
|
|
/* Properties */
|
|
|
|
"^[ \t]*(((static|public|internal|private|protected|new|virtual|sealed|override|unsafe)[ \t]+)*[][<>@.~_[:alnum:]]+[ \t]+[@._[:alnum:]]+)[ \t]*$\n"
|
|
|
|
/* Type definitions */
|
|
|
|
"^[ \t]*(((static|public|internal|private|protected|new|unsafe|sealed|abstract|partial)[ \t]+)*(class|enum|interface|struct)[ \t]+.*)$\n"
|
|
|
|
/* Namespace */
|
|
|
|
"^[ \t]*(namespace[ \t]+.*)$",
|
|
|
|
/* -- */
|
|
|
|
"[a-zA-Z_][a-zA-Z0-9_]*"
|
|
|
|
"|[-+0-9.e]+[fFlL]?|0[xXbB]?[0-9a-fA-F]+[lL]?"
|
2011-01-12 00:48:50 +03:00
|
|
|
"|[-+*/<>%&^|=!]=|--|\\+\\+|<<=?|>>=?|&&|\\|\\||::|->"),
|
diff: introduce diff.<driver>.binary
The "diff" gitattribute is somewhat overloaded right now. It
can say one of three things:
1. this file is definitely binary, or definitely not
(i.e., diff or !diff)
2. this file should use an external diff engine (i.e.,
diff=foo, diff.foo.command = custom-script)
3. this file should use particular funcname patterns
(i.e., diff=foo, diff.foo.(x?)funcname = some-regex)
Most of the time, there is no conflict between these uses,
since using one implies that the other is irrelevant (e.g.,
an external diff engine will decide for itself whether the
file is binary).
However, there is at least one conflicting situation: there
is no way to say "use the regular rules to determine whether
this file is binary, but if we do diff it textually, use
this funcname pattern." That is, currently setting diff=foo
indicates that the file is definitely text.
This patch introduces a "binary" config option for a diff
driver, so that one can explicitly set diff.foo.binary. We
default this value to "don't know". That is, setting a diff
attribute to "foo" and using "diff.foo.funcname" will have
no effect on the binaryness of a file. To get the current
behavior, one can set diff.foo.binary to true.
This patch also has one additional advantage: it cleans up
the interface to the userdiff code a bit. Before, calling
code had to know more about whether attributes were false,
true, or unset to determine binaryness. Now that binaryness
is a property of a driver, we can represent these situations
just by passing back a driver struct.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-06 01:43:36 +04:00
|
|
|
{ "default", NULL, -1, { NULL, 0 } },
|
2008-10-06 01:43:21 +04:00
|
|
|
};
|
2009-01-17 19:29:48 +03:00
|
|
|
#undef PATTERNS
|
2010-09-10 20:18:14 +04:00
|
|
|
#undef IPATTERN
|
2008-10-06 01:43:21 +04:00
|
|
|
|
|
|
|
static struct userdiff_driver driver_true = {
|
|
|
|
"diff=true",
|
|
|
|
NULL,
|
diff: introduce diff.<driver>.binary
The "diff" gitattribute is somewhat overloaded right now. It
can say one of three things:
1. this file is definitely binary, or definitely not
(i.e., diff or !diff)
2. this file should use an external diff engine (i.e.,
diff=foo, diff.foo.command = custom-script)
3. this file should use particular funcname patterns
(i.e., diff=foo, diff.foo.(x?)funcname = some-regex)
Most of the time, there is no conflict between these uses,
since using one implies that the other is irrelevant (e.g.,
an external diff engine will decide for itself whether the
file is binary).
However, there is at least one conflicting situation: there
is no way to say "use the regular rules to determine whether
this file is binary, but if we do diff it textually, use
this funcname pattern." That is, currently setting diff=foo
indicates that the file is definitely text.
This patch introduces a "binary" config option for a diff
driver, so that one can explicitly set diff.foo.binary. We
default this value to "don't know". That is, setting a diff
attribute to "foo" and using "diff.foo.funcname" will have
no effect on the binaryness of a file. To get the current
behavior, one can set diff.foo.binary to true.
This patch also has one additional advantage: it cleans up
the interface to the userdiff code a bit. Before, calling
code had to know more about whether attributes were false,
true, or unset to determine binaryness. Now that binaryness
is a property of a driver, we can represent these situations
just by passing back a driver struct.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-06 01:43:36 +04:00
|
|
|
0,
|
2008-10-06 01:43:21 +04:00
|
|
|
{ NULL, 0 }
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct userdiff_driver driver_false = {
|
|
|
|
"!diff",
|
|
|
|
NULL,
|
diff: introduce diff.<driver>.binary
The "diff" gitattribute is somewhat overloaded right now. It
can say one of three things:
1. this file is definitely binary, or definitely not
(i.e., diff or !diff)
2. this file should use an external diff engine (i.e.,
diff=foo, diff.foo.command = custom-script)
3. this file should use particular funcname patterns
(i.e., diff=foo, diff.foo.(x?)funcname = some-regex)
Most of the time, there is no conflict between these uses,
since using one implies that the other is irrelevant (e.g.,
an external diff engine will decide for itself whether the
file is binary).
However, there is at least one conflicting situation: there
is no way to say "use the regular rules to determine whether
this file is binary, but if we do diff it textually, use
this funcname pattern." That is, currently setting diff=foo
indicates that the file is definitely text.
This patch introduces a "binary" config option for a diff
driver, so that one can explicitly set diff.foo.binary. We
default this value to "don't know". That is, setting a diff
attribute to "foo" and using "diff.foo.funcname" will have
no effect on the binaryness of a file. To get the current
behavior, one can set diff.foo.binary to true.
This patch also has one additional advantage: it cleans up
the interface to the userdiff code a bit. Before, calling
code had to know more about whether attributes were false,
true, or unset to determine binaryness. Now that binaryness
is a property of a driver, we can represent these situations
just by passing back a driver struct.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-06 01:43:36 +04:00
|
|
|
1,
|
2008-10-06 01:43:21 +04:00
|
|
|
{ NULL, 0 }
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct userdiff_driver *userdiff_find_by_namelen(const char *k, int len)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
for (i = 0; i < ndrivers; i++) {
|
|
|
|
struct userdiff_driver *drv = drivers + i;
|
|
|
|
if (!strncmp(drv->name, k, len) && !drv->name[len])
|
|
|
|
return drv;
|
|
|
|
}
|
|
|
|
for (i = 0; i < ARRAY_SIZE(builtin_drivers); i++) {
|
|
|
|
struct userdiff_driver *drv = builtin_drivers + i;
|
|
|
|
if (!strncmp(drv->name, k, len) && !drv->name[len])
|
|
|
|
return drv;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int parse_funcname(struct userdiff_funcname *f, const char *k,
|
|
|
|
const char *v, int cflags)
|
|
|
|
{
|
|
|
|
if (git_config_string(&f->pattern, k, v) < 0)
|
|
|
|
return -1;
|
|
|
|
f->cflags = cflags;
|
drop odd return value semantics from userdiff_config
When the userdiff_config function was introduced in be58e70
(diff: unify external diff and funcname parsing code,
2008-10-05), it used a return value convention unlike any
other config callback. Like other callbacks, it used "-1" to
signal error. But it returned "1" to indicate that it found
something, and "0" otherwise; other callbacks simply
returned "0" to indicate that no error occurred.
This distinction was necessary at the time, because the
userdiff namespace overlapped slightly with the color
configuration namespace. So "diff.color.foo" could mean "the
'foo' slot of diff coloring" or "the 'foo' component of the
"color" userdiff driver". Because the color-parsing code
would die on an unknown color slot, we needed the userdiff
code to indicate that it had matched the variable, letting
us bypass the color-parsing code entirely.
Later, in 8b8e862 (ignore unknown color configuration,
2009-12-12), the color-parsing code learned to silently
ignore unknown slots. This means we no longer need to
protect userdiff-matched variables from reaching the
color-parsing code.
We can therefore change the userdiff_config calling
convention to a more normal one. This drops some code from
each caller, which is nice. But more importantly, it reduces
the cognitive load for readers who may wonder why
userdiff_config is unlike every other config callback.
There's no need to add a new test confirming that this
works; t4020 already contains a test that sets
diff.color.external.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-07 22:23:02 +04:00
|
|
|
return 0;
|
2008-10-06 01:43:21 +04:00
|
|
|
}
|
|
|
|
|
diff: introduce diff.<driver>.binary
The "diff" gitattribute is somewhat overloaded right now. It
can say one of three things:
1. this file is definitely binary, or definitely not
(i.e., diff or !diff)
2. this file should use an external diff engine (i.e.,
diff=foo, diff.foo.command = custom-script)
3. this file should use particular funcname patterns
(i.e., diff=foo, diff.foo.(x?)funcname = some-regex)
Most of the time, there is no conflict between these uses,
since using one implies that the other is irrelevant (e.g.,
an external diff engine will decide for itself whether the
file is binary).
However, there is at least one conflicting situation: there
is no way to say "use the regular rules to determine whether
this file is binary, but if we do diff it textually, use
this funcname pattern." That is, currently setting diff=foo
indicates that the file is definitely text.
This patch introduces a "binary" config option for a diff
driver, so that one can explicitly set diff.foo.binary. We
default this value to "don't know". That is, setting a diff
attribute to "foo" and using "diff.foo.funcname" will have
no effect on the binaryness of a file. To get the current
behavior, one can set diff.foo.binary to true.
This patch also has one additional advantage: it cleans up
the interface to the userdiff code a bit. Before, calling
code had to know more about whether attributes were false,
true, or unset to determine binaryness. Now that binaryness
is a property of a driver, we can represent these situations
just by passing back a driver struct.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-06 01:43:36 +04:00
|
|
|
static int parse_tristate(int *b, const char *k, const char *v)
|
|
|
|
{
|
|
|
|
if (v && !strcasecmp(v, "auto"))
|
|
|
|
*b = -1;
|
|
|
|
else
|
|
|
|
*b = git_config_bool(k, v);
|
drop odd return value semantics from userdiff_config
When the userdiff_config function was introduced in be58e70
(diff: unify external diff and funcname parsing code,
2008-10-05), it used a return value convention unlike any
other config callback. Like other callbacks, it used "-1" to
signal error. But it returned "1" to indicate that it found
something, and "0" otherwise; other callbacks simply
returned "0" to indicate that no error occurred.
This distinction was necessary at the time, because the
userdiff namespace overlapped slightly with the color
configuration namespace. So "diff.color.foo" could mean "the
'foo' slot of diff coloring" or "the 'foo' component of the
"color" userdiff driver". Because the color-parsing code
would die on an unknown color slot, we needed the userdiff
code to indicate that it had matched the variable, letting
us bypass the color-parsing code entirely.
Later, in 8b8e862 (ignore unknown color configuration,
2009-12-12), the color-parsing code learned to silently
ignore unknown slots. This means we no longer need to
protect userdiff-matched variables from reaching the
color-parsing code.
We can therefore change the userdiff_config calling
convention to a more normal one. This drops some code from
each caller, which is nice. But more importantly, it reduces
the cognitive load for readers who may wonder why
userdiff_config is unlike every other config callback.
There's no need to add a new test confirming that this
works; t4020 already contains a test that sets
diff.color.external.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-07 22:23:02 +04:00
|
|
|
return 0;
|
diff: introduce diff.<driver>.binary
The "diff" gitattribute is somewhat overloaded right now. It
can say one of three things:
1. this file is definitely binary, or definitely not
(i.e., diff or !diff)
2. this file should use an external diff engine (i.e.,
diff=foo, diff.foo.command = custom-script)
3. this file should use particular funcname patterns
(i.e., diff=foo, diff.foo.(x?)funcname = some-regex)
Most of the time, there is no conflict between these uses,
since using one implies that the other is irrelevant (e.g.,
an external diff engine will decide for itself whether the
file is binary).
However, there is at least one conflicting situation: there
is no way to say "use the regular rules to determine whether
this file is binary, but if we do diff it textually, use
this funcname pattern." That is, currently setting diff=foo
indicates that the file is definitely text.
This patch introduces a "binary" config option for a diff
driver, so that one can explicitly set diff.foo.binary. We
default this value to "don't know". That is, setting a diff
attribute to "foo" and using "diff.foo.funcname" will have
no effect on the binaryness of a file. To get the current
behavior, one can set diff.foo.binary to true.
This patch also has one additional advantage: it cleans up
the interface to the userdiff code a bit. Before, calling
code had to know more about whether attributes were false,
true, or unset to determine binaryness. Now that binaryness
is a property of a driver, we can represent these situations
just by passing back a driver struct.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-06 01:43:36 +04:00
|
|
|
}
|
|
|
|
|
2010-04-02 04:12:15 +04:00
|
|
|
static int parse_bool(int *b, const char *k, const char *v)
|
|
|
|
{
|
|
|
|
*b = git_config_bool(k, v);
|
drop odd return value semantics from userdiff_config
When the userdiff_config function was introduced in be58e70
(diff: unify external diff and funcname parsing code,
2008-10-05), it used a return value convention unlike any
other config callback. Like other callbacks, it used "-1" to
signal error. But it returned "1" to indicate that it found
something, and "0" otherwise; other callbacks simply
returned "0" to indicate that no error occurred.
This distinction was necessary at the time, because the
userdiff namespace overlapped slightly with the color
configuration namespace. So "diff.color.foo" could mean "the
'foo' slot of diff coloring" or "the 'foo' component of the
"color" userdiff driver". Because the color-parsing code
would die on an unknown color slot, we needed the userdiff
code to indicate that it had matched the variable, letting
us bypass the color-parsing code entirely.
Later, in 8b8e862 (ignore unknown color configuration,
2009-12-12), the color-parsing code learned to silently
ignore unknown slots. This means we no longer need to
protect userdiff-matched variables from reaching the
color-parsing code.
We can therefore change the userdiff_config calling
convention to a more normal one. This drops some code from
each caller, which is nice. But more importantly, it reduces
the cognitive load for readers who may wonder why
userdiff_config is unlike every other config callback.
There's no need to add a new test confirming that this
works; t4020 already contains a test that sets
diff.color.external.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-07 22:23:02 +04:00
|
|
|
return 0;
|
2010-04-02 04:12:15 +04:00
|
|
|
}
|
|
|
|
|
2008-10-26 07:45:55 +03:00
|
|
|
int userdiff_config(const char *k, const char *v)
|
2008-10-06 01:43:21 +04:00
|
|
|
{
|
|
|
|
struct userdiff_driver *drv;
|
2013-01-23 10:25:07 +04:00
|
|
|
const char *name, *type;
|
|
|
|
int namelen;
|
|
|
|
|
|
|
|
if (parse_config_key(k, "diff", &name, &namelen, &type) || !name)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
drv = userdiff_find_by_namelen(name, namelen);
|
|
|
|
if (!drv) {
|
|
|
|
ALLOC_GROW(drivers, ndrivers+1, drivers_alloc);
|
|
|
|
drv = &drivers[ndrivers++];
|
|
|
|
memset(drv, 0, sizeof(*drv));
|
|
|
|
drv->name = xmemdupz(name, namelen);
|
|
|
|
drv->binary = -1;
|
|
|
|
}
|
2008-10-06 01:43:21 +04:00
|
|
|
|
2013-01-23 10:25:07 +04:00
|
|
|
if (!strcmp(type, "funcname"))
|
2008-10-06 01:43:21 +04:00
|
|
|
return parse_funcname(&drv->funcname, k, v, 0);
|
2013-01-23 10:25:07 +04:00
|
|
|
if (!strcmp(type, "xfuncname"))
|
2008-10-06 01:43:21 +04:00
|
|
|
return parse_funcname(&drv->funcname, k, v, REG_EXTENDED);
|
2013-01-23 10:25:07 +04:00
|
|
|
if (!strcmp(type, "binary"))
|
diff: introduce diff.<driver>.binary
The "diff" gitattribute is somewhat overloaded right now. It
can say one of three things:
1. this file is definitely binary, or definitely not
(i.e., diff or !diff)
2. this file should use an external diff engine (i.e.,
diff=foo, diff.foo.command = custom-script)
3. this file should use particular funcname patterns
(i.e., diff=foo, diff.foo.(x?)funcname = some-regex)
Most of the time, there is no conflict between these uses,
since using one implies that the other is irrelevant (e.g.,
an external diff engine will decide for itself whether the
file is binary).
However, there is at least one conflicting situation: there
is no way to say "use the regular rules to determine whether
this file is binary, but if we do diff it textually, use
this funcname pattern." That is, currently setting diff=foo
indicates that the file is definitely text.
This patch introduces a "binary" config option for a diff
driver, so that one can explicitly set diff.foo.binary. We
default this value to "don't know". That is, setting a diff
attribute to "foo" and using "diff.foo.funcname" will have
no effect on the binaryness of a file. To get the current
behavior, one can set diff.foo.binary to true.
This patch also has one additional advantage: it cleans up
the interface to the userdiff code a bit. Before, calling
code had to know more about whether attributes were false,
true, or unset to determine binaryness. Now that binaryness
is a property of a driver, we can represent these situations
just by passing back a driver struct.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-06 01:43:36 +04:00
|
|
|
return parse_tristate(&drv->binary, k, v);
|
2013-01-23 10:25:07 +04:00
|
|
|
if (!strcmp(type, "command"))
|
drop odd return value semantics from userdiff_config
When the userdiff_config function was introduced in be58e70
(diff: unify external diff and funcname parsing code,
2008-10-05), it used a return value convention unlike any
other config callback. Like other callbacks, it used "-1" to
signal error. But it returned "1" to indicate that it found
something, and "0" otherwise; other callbacks simply
returned "0" to indicate that no error occurred.
This distinction was necessary at the time, because the
userdiff namespace overlapped slightly with the color
configuration namespace. So "diff.color.foo" could mean "the
'foo' slot of diff coloring" or "the 'foo' component of the
"color" userdiff driver". Because the color-parsing code
would die on an unknown color slot, we needed the userdiff
code to indicate that it had matched the variable, letting
us bypass the color-parsing code entirely.
Later, in 8b8e862 (ignore unknown color configuration,
2009-12-12), the color-parsing code learned to silently
ignore unknown slots. This means we no longer need to
protect userdiff-matched variables from reaching the
color-parsing code.
We can therefore change the userdiff_config calling
convention to a more normal one. This drops some code from
each caller, which is nice. But more importantly, it reduces
the cognitive load for readers who may wonder why
userdiff_config is unlike every other config callback.
There's no need to add a new test confirming that this
works; t4020 already contains a test that sets
diff.color.external.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-07 22:23:02 +04:00
|
|
|
return git_config_string(&drv->external, k, v);
|
2013-01-23 10:25:07 +04:00
|
|
|
if (!strcmp(type, "textconv"))
|
drop odd return value semantics from userdiff_config
When the userdiff_config function was introduced in be58e70
(diff: unify external diff and funcname parsing code,
2008-10-05), it used a return value convention unlike any
other config callback. Like other callbacks, it used "-1" to
signal error. But it returned "1" to indicate that it found
something, and "0" otherwise; other callbacks simply
returned "0" to indicate that no error occurred.
This distinction was necessary at the time, because the
userdiff namespace overlapped slightly with the color
configuration namespace. So "diff.color.foo" could mean "the
'foo' slot of diff coloring" or "the 'foo' component of the
"color" userdiff driver". Because the color-parsing code
would die on an unknown color slot, we needed the userdiff
code to indicate that it had matched the variable, letting
us bypass the color-parsing code entirely.
Later, in 8b8e862 (ignore unknown color configuration,
2009-12-12), the color-parsing code learned to silently
ignore unknown slots. This means we no longer need to
protect userdiff-matched variables from reaching the
color-parsing code.
We can therefore change the userdiff_config calling
convention to a more normal one. This drops some code from
each caller, which is nice. But more importantly, it reduces
the cognitive load for readers who may wonder why
userdiff_config is unlike every other config callback.
There's no need to add a new test confirming that this
works; t4020 already contains a test that sets
diff.color.external.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-07 22:23:02 +04:00
|
|
|
return git_config_string(&drv->textconv, k, v);
|
2013-01-23 10:25:07 +04:00
|
|
|
if (!strcmp(type, "cachetextconv"))
|
2010-04-02 04:12:15 +04:00
|
|
|
return parse_bool(&drv->textconv_want_cache, k, v);
|
2013-01-23 10:25:07 +04:00
|
|
|
if (!strcmp(type, "wordregex"))
|
drop odd return value semantics from userdiff_config
When the userdiff_config function was introduced in be58e70
(diff: unify external diff and funcname parsing code,
2008-10-05), it used a return value convention unlike any
other config callback. Like other callbacks, it used "-1" to
signal error. But it returned "1" to indicate that it found
something, and "0" otherwise; other callbacks simply
returned "0" to indicate that no error occurred.
This distinction was necessary at the time, because the
userdiff namespace overlapped slightly with the color
configuration namespace. So "diff.color.foo" could mean "the
'foo' slot of diff coloring" or "the 'foo' component of the
"color" userdiff driver". Because the color-parsing code
would die on an unknown color slot, we needed the userdiff
code to indicate that it had matched the variable, letting
us bypass the color-parsing code entirely.
Later, in 8b8e862 (ignore unknown color configuration,
2009-12-12), the color-parsing code learned to silently
ignore unknown slots. This means we no longer need to
protect userdiff-matched variables from reaching the
color-parsing code.
We can therefore change the userdiff_config calling
convention to a more normal one. This drops some code from
each caller, which is nice. But more importantly, it reduces
the cognitive load for readers who may wonder why
userdiff_config is unlike every other config callback.
There's no need to add a new test confirming that this
works; t4020 already contains a test that sets
diff.color.external.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-07 22:23:02 +04:00
|
|
|
return git_config_string(&drv->word_regex, k, v);
|
2008-10-06 01:43:21 +04:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct userdiff_driver *userdiff_find_by_name(const char *name) {
|
|
|
|
int len = strlen(name);
|
|
|
|
return userdiff_find_by_namelen(name, len);
|
|
|
|
}
|
|
|
|
|
|
|
|
struct userdiff_driver *userdiff_find_by_path(const char *path)
|
|
|
|
{
|
|
|
|
static struct git_attr *attr;
|
|
|
|
struct git_attr_check check;
|
|
|
|
|
|
|
|
if (!attr)
|
2010-01-17 07:39:59 +03:00
|
|
|
attr = git_attr("diff");
|
2008-10-06 01:43:21 +04:00
|
|
|
check.attr = attr;
|
|
|
|
|
|
|
|
if (!path)
|
|
|
|
return NULL;
|
2011-08-04 08:36:33 +04:00
|
|
|
if (git_check_attr(path, 1, &check))
|
2008-10-06 01:43:21 +04:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
if (ATTR_TRUE(check.value))
|
|
|
|
return &driver_true;
|
|
|
|
if (ATTR_FALSE(check.value))
|
|
|
|
return &driver_false;
|
|
|
|
if (ATTR_UNSET(check.value))
|
|
|
|
return NULL;
|
|
|
|
return userdiff_find_by_name(check.value);
|
|
|
|
}
|
2011-05-24 00:30:14 +04:00
|
|
|
|
|
|
|
struct userdiff_driver *userdiff_get_textconv(struct userdiff_driver *driver)
|
|
|
|
{
|
|
|
|
if (!driver->textconv)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
if (driver->textconv_want_cache && !driver->textconv_cache) {
|
|
|
|
struct notes_cache *c = xmalloc(sizeof(*c));
|
|
|
|
struct strbuf name = STRBUF_INIT;
|
|
|
|
|
|
|
|
strbuf_addf(&name, "textconv/%s", driver->name);
|
|
|
|
notes_cache_init(c, name.buf, driver->textconv);
|
|
|
|
driver->textconv_cache = c;
|
|
|
|
}
|
|
|
|
|
|
|
|
return driver;
|
|
|
|
}
|