Re: git checkout error
Junio, giving the user a better error message is certainly an improvement. But would not be another improvement to describe better the command syntax so as to help the user write the command right in the first place? After all, what is the syntax section in commands for? If I had seen in the syntax: git checkout [-q] [-f] [-m] [ [--track|--no-track](-b|-B) new_branch] [start_point] I would have written the command correctly, and not even stumbled on a misleading error message. Note that the above syntax is exactly what the command must look like. The syntax is mostly a description of the form of command for the user. Internally, the implementer can use it or can even use a different one (e.g. a more lenient one and detect errors at the semantic level instead). But here what matters is not how the command is implemented, but how the user has to form it. Why it is so difficult to convince people to make documentation better? -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git svn clone options
乙酸鋰 ch3co...@gmail.com writes: Could you clarify --branch option, is it the same as --branches. Switches can be abbreviated as long as they are unambiguous. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git checkout error
Angelo Borsotti angelo.borso...@gmail.com writes: Why it is so difficult to convince people to make documentation better? It is not difficult. The discussion on this list is usually done via patches, and without one, constant talking is buried in other noise and often go unnoticed. There is however an issue about documentation consistency. Do we use elsewhere ( A | B | C ... ) to denote You must write one (and only one) among A, B, C, ... consistently in the documentation? An ancient discussion $gmane/72243 might be of interest to kickstart such a documentation clean-up effort. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/7] Tying loose ends on grep-pcre
It took longer than expected, but here is a reroll of the previous series to bring more recent git grep enhancements to the --grep option of commands in git log family. The early part of the series (1-3) refactors the code that reads configuration items related to grep and the code that mixes the result with the command line options to prepare grep_opt, which so far lived in builtin/grep.c, and moves them to the grep.[ch] at the top-level. The middle part (4-6) reuses the code to set-up grep_opt refactored by the earlier part of the series on revs-grep_filter that is used in git log --grep=... processing. It incidentally fixes a small bug where git log -F -E --grep='ere' did not look for matches to the pattern in extended regular expression, and adds --basic-regexp and --perl-regexp command line options to git log family for completeness. The last one teaches git log family to honor the grep.* configuration variables, e.g. grep.patterntype, so that you can say git -c grep.patterntype=perl log --grep='(?:pcre)'. Obviously, it is too late for this cycle and will not graduate to 'master' before the 1.8.0 final. Junio C Hamano (7): builtin/grep.c: make configuration callback more reusable grep: move the configuration parsing logic to grep.[ch] grep: move pattern-type bits support to top-level grep.[ch] revisions: initialize revs-grep_filter using grep_init() log --grep: use the same helper to set -E/-F options as git grep log --grep: accept --basic-regexp and --perl-regexp log: honor grep.* configuration Documentation/rev-list-options.txt | 10 +++ builtin/grep.c | 133 ++-- builtin/log.c | 8 +- grep.c | 177 + grep.h | 6 ++ revision.c | 14 ++- t/t4202-log.sh | 6 ++ 7 files changed, 225 insertions(+), 129 deletions(-) -- 1.8.0.rc1.76.g5a375e6 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/7] builtin/grep.c: make configuration callback more reusable
The grep_config() function takes one instance of grep_opt as its
callback parameter, and populates it by running git_config().
This has three practical implications:
- You have to have an instance of grep_opt already when you call
the configuration, but that is not necessarily always true. You
may be trying to initialize the grep_filter member of rev_info,
but are not ready to call init_revisions() on it yet.
- It is not easy to enhance grep_config() in such a way to make it
cascade to other callback functions to grab other variables in
one call of git_config(); grep_config() can be cascaded into from
other callbacks, but it has to be at the leaf level of a cascade.
- If you ever need to use more than one instance of grep_opt, you
will have to open and read the configuration file(s) every time
you initialize them.
Rearrange the configuration mechanism and model it after how diff
configuration variables are handled. An early call to git_config()
reads and remembers the values taken from the configuration in the
default template, and a separate call to grep_init() uses this
template to instantiate a grep_opt.
The next step will be to move some of this out of this file so that
the other user of the grep machinery (i.e. log) can use it.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/grep.c | 104 +++--
1 file changed, 79 insertions(+), 25 deletions(-)
diff --git a/builtin/grep.c b/builtin/grep.c
index 82530a6..83232c9 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -308,9 +308,41 @@ static void grep_pattern_type_options(const int
pattern_type, struct grep_opt *o
}
}
+static struct grep_opt grep_defaults;
+
+/*
+ * Initialize the grep_defaults template with hardcoded defaults.
+ * We could let the compiler do this, but without C99 initializers
+ * the code gets unwieldy and unreadable, so...
+ */
+static void init_grep_defaults(void)
+{
+ struct grep_opt *opt = grep_defaults;
+
+ memset(opt, 0, sizeof(*opt));
+ opt-relative = 1;
+ opt-pathname = 1;
+ opt-regflags = REG_NEWLINE;
+ opt-max_depth = -1;
+ opt-pattern_type_option = GREP_PATTERN_TYPE_UNSPECIFIED;
+ opt-extended_regexp_option = 0;
+ strcpy(opt-color_context, );
+ strcpy(opt-color_filename, );
+ strcpy(opt-color_function, );
+ strcpy(opt-color_lineno, );
+ strcpy(opt-color_match, GIT_COLOR_BOLD_RED);
+ strcpy(opt-color_selected, );
+ strcpy(opt-color_sep, GIT_COLOR_CYAN);
+ opt-color = -1;
+}
+
+/*
+ * Read the configuration file once and store it in
+ * the grep_defaults template.
+ */
static int grep_config(const char *var, const char *value, void *cb)
{
- struct grep_opt *opt = cb;
+ struct grep_opt *opt = grep_defaults;
char *color = NULL;
if (userdiff_config(var, value) 0)
@@ -327,7 +359,7 @@ static int grep_config(const char *var, const char *value,
void *cb)
if (!strcmp(var, grep.patterntype)) {
opt-pattern_type_option = parse_pattern_type_arg(var, value);
return 0;
- }
+ }
if (!strcmp(var, grep.linenumber)) {
opt-linenum = git_config_bool(var, value);
@@ -350,8 +382,7 @@ static int grep_config(const char *var, const char *value,
void *cb)
color = opt-color_selected;
else if (!strcmp(var, color.grep.separator))
color = opt-color_sep;
- else
- return git_color_default_config(var, value, cb);
+
if (color) {
if (!value)
return config_error_nonbool(var);
@@ -360,6 +391,47 @@ static int grep_config(const char *var, const char *value,
void *cb)
return 0;
}
+/*
+ * Initialize one instance of grep_opt and copy the
+ * default values from the template we read the configuration
+ * information in an earlier call to git_config(grep_config).
+ */
+static void grep_init(struct grep_opt *opt, const char *prefix)
+{
+ struct grep_opt *def = grep_defaults;
+
+ memset(opt, 0, sizeof(*opt));
+ opt-prefix = prefix;
+ opt-prefix_length = (prefix *prefix) ? strlen(prefix) : 0;
+ opt-pattern_tail = opt-pattern_list;
+ opt-header_tail = opt-header_list;
+
+ opt-color = def-color;
+ opt-extended_regexp_option = def-extended_regexp_option;
+ opt-pattern_type_option = def-pattern_type_option;
+ opt-linenum = def-linenum;
+ opt-max_depth = def-max_depth;
+ opt-pathname = def-pathname;
+ opt-regflags = def-regflags;
+ opt-relative = def-relative;
+
+ strcpy(opt-color_context, def-color_context);
+ strcpy(opt-color_filename, def-color_filename);
+ strcpy(opt-color_function, def-color_function);
+ strcpy(opt-color_lineno, def-color_lineno);
+ strcpy(opt-color_match, def-color_match);
+ strcpy(opt-color_selected,
[PATCH v2 2/7] grep: move the configuration parsing logic to grep.[ch]
The configuration handling is a library-ish part of this program,
that is not specific to git grep command. It should be reusable
by log and others.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/grep.c | 131 -
grep.c | 130
grep.h | 4 ++
3 files changed, 134 insertions(+), 131 deletions(-)
diff --git a/builtin/grep.c b/builtin/grep.c
index 83232c9..b63a9f8 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -261,21 +261,6 @@ static int wait_all(void)
}
#endif
-static int parse_pattern_type_arg(const char *opt, const char *arg)
-{
- if (!strcmp(arg, default))
- return GREP_PATTERN_TYPE_UNSPECIFIED;
- else if (!strcmp(arg, basic))
- return GREP_PATTERN_TYPE_BRE;
- else if (!strcmp(arg, extended))
- return GREP_PATTERN_TYPE_ERE;
- else if (!strcmp(arg, fixed))
- return GREP_PATTERN_TYPE_FIXED;
- else if (!strcmp(arg, perl))
- return GREP_PATTERN_TYPE_PCRE;
- die(bad %s argument: %s, opt, arg);
-}
-
static void grep_pattern_type_options(const int pattern_type, struct grep_opt
*opt)
{
switch (pattern_type) {
@@ -308,122 +293,6 @@ static void grep_pattern_type_options(const int
pattern_type, struct grep_opt *o
}
}
-static struct grep_opt grep_defaults;
-
-/*
- * Initialize the grep_defaults template with hardcoded defaults.
- * We could let the compiler do this, but without C99 initializers
- * the code gets unwieldy and unreadable, so...
- */
-static void init_grep_defaults(void)
-{
- struct grep_opt *opt = grep_defaults;
-
- memset(opt, 0, sizeof(*opt));
- opt-relative = 1;
- opt-pathname = 1;
- opt-regflags = REG_NEWLINE;
- opt-max_depth = -1;
- opt-pattern_type_option = GREP_PATTERN_TYPE_UNSPECIFIED;
- opt-extended_regexp_option = 0;
- strcpy(opt-color_context, );
- strcpy(opt-color_filename, );
- strcpy(opt-color_function, );
- strcpy(opt-color_lineno, );
- strcpy(opt-color_match, GIT_COLOR_BOLD_RED);
- strcpy(opt-color_selected, );
- strcpy(opt-color_sep, GIT_COLOR_CYAN);
- opt-color = -1;
-}
-
-/*
- * Read the configuration file once and store it in
- * the grep_defaults template.
- */
-static int grep_config(const char *var, const char *value, void *cb)
-{
- struct grep_opt *opt = grep_defaults;
- char *color = NULL;
-
- if (userdiff_config(var, value) 0)
- return -1;
-
- if (!strcmp(var, grep.extendedregexp)) {
- if (git_config_bool(var, value))
- opt-extended_regexp_option = 1;
- else
- opt-extended_regexp_option = 0;
- return 0;
- }
-
- if (!strcmp(var, grep.patterntype)) {
- opt-pattern_type_option = parse_pattern_type_arg(var, value);
- return 0;
- }
-
- if (!strcmp(var, grep.linenumber)) {
- opt-linenum = git_config_bool(var, value);
- return 0;
- }
-
- if (!strcmp(var, color.grep))
- opt-color = git_config_colorbool(var, value);
- else if (!strcmp(var, color.grep.context))
- color = opt-color_context;
- else if (!strcmp(var, color.grep.filename))
- color = opt-color_filename;
- else if (!strcmp(var, color.grep.function))
- color = opt-color_function;
- else if (!strcmp(var, color.grep.linenumber))
- color = opt-color_lineno;
- else if (!strcmp(var, color.grep.match))
- color = opt-color_match;
- else if (!strcmp(var, color.grep.selected))
- color = opt-color_selected;
- else if (!strcmp(var, color.grep.separator))
- color = opt-color_sep;
-
- if (color) {
- if (!value)
- return config_error_nonbool(var);
- color_parse(value, var, color);
- }
- return 0;
-}
-
-/*
- * Initialize one instance of grep_opt and copy the
- * default values from the template we read the configuration
- * information in an earlier call to git_config(grep_config).
- */
-static void grep_init(struct grep_opt *opt, const char *prefix)
-{
- struct grep_opt *def = grep_defaults;
-
- memset(opt, 0, sizeof(*opt));
- opt-prefix = prefix;
- opt-prefix_length = (prefix *prefix) ? strlen(prefix) : 0;
- opt-pattern_tail = opt-pattern_list;
- opt-header_tail = opt-header_list;
-
- opt-color = def-color;
- opt-extended_regexp_option = def-extended_regexp_option;
- opt-pattern_type_option = def-pattern_type_option;
- opt-linenum = def-linenum;
- opt-max_depth = def-max_depth;
- opt-pathname = def-pathname;
- opt-regflags = def-regflags;
-
[PATCH v2 3/7] grep: move pattern-type bits support to top-level grep.[ch]
Switching between -E/-G/-P/-F correctly needs a lot more than just
flipping opt-regflags bit these days, and we have a nice helper
function buried in builtin/grep.c for the sole use of git grep.
Extract it so that log --grep family can also use it.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/grep.c | 40 +---
grep.c | 42 ++
grep.h | 2 ++
3 files changed, 45 insertions(+), 39 deletions(-)
diff --git a/builtin/grep.c b/builtin/grep.c
index b63a9f8..c296e6f 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -261,38 +261,6 @@ static int wait_all(void)
}
#endif
-static void grep_pattern_type_options(const int pattern_type, struct grep_opt
*opt)
-{
- switch (pattern_type) {
- case GREP_PATTERN_TYPE_UNSPECIFIED:
- /* fall through */
-
- case GREP_PATTERN_TYPE_BRE:
- opt-fixed = 0;
- opt-pcre = 0;
- opt-regflags = ~REG_EXTENDED;
- break;
-
- case GREP_PATTERN_TYPE_ERE:
- opt-fixed = 0;
- opt-pcre = 0;
- opt-regflags |= REG_EXTENDED;
- break;
-
- case GREP_PATTERN_TYPE_FIXED:
- opt-fixed = 1;
- opt-pcre = 0;
- opt-regflags = ~REG_EXTENDED;
- break;
-
- case GREP_PATTERN_TYPE_PCRE:
- opt-fixed = 0;
- opt-pcre = 1;
- opt-regflags = ~REG_EXTENDED;
- break;
- }
-}
-
static int grep_cmd_config(const char *var, const char *value, void *cb)
{
int st = grep_config(var, value, cb);
@@ -798,13 +766,7 @@ int cmd_grep(int argc, const char **argv, const char
*prefix)
PARSE_OPT_KEEP_DASHDASH |
PARSE_OPT_STOP_AT_NON_OPTION |
PARSE_OPT_NO_INTERNAL_HELP);
-
- if (pattern_type_arg != GREP_PATTERN_TYPE_UNSPECIFIED)
- grep_pattern_type_options(pattern_type_arg, opt);
- else if (opt.pattern_type_option != GREP_PATTERN_TYPE_UNSPECIFIED)
- grep_pattern_type_options(opt.pattern_type_option, opt);
- else if (opt.extended_regexp_option)
- grep_pattern_type_options(GREP_PATTERN_TYPE_ERE, opt);
+ grep_commit_pattern_type(pattern_type_arg, opt);
if (use_index !startup_info-have_repository)
/* die the same way as if we did it at the beginning */
diff --git a/grep.c b/grep.c
index 621e6ec..279a559 100644
--- a/grep.c
+++ b/grep.c
@@ -137,6 +137,48 @@ void grep_init(struct grep_opt *opt, const char *prefix)
strcpy(opt-color_sep, def-color_sep);
}
+void grep_commit_pattern_type(enum grep_pattern_type pattern_type, struct
grep_opt *opt)
+{
+ if (pattern_type != GREP_PATTERN_TYPE_UNSPECIFIED)
+ grep_set_pattern_type_option(pattern_type, opt);
+ else if (opt-pattern_type_option != GREP_PATTERN_TYPE_UNSPECIFIED)
+ grep_set_pattern_type_option(opt-pattern_type_option, opt);
+ else if (opt-extended_regexp_option)
+ grep_set_pattern_type_option(GREP_PATTERN_TYPE_ERE, opt);
+}
+
+void grep_set_pattern_type_option(enum grep_pattern_type pattern_type, struct
grep_opt *opt)
+{
+ switch (pattern_type) {
+ case GREP_PATTERN_TYPE_UNSPECIFIED:
+ /* fall through */
+
+ case GREP_PATTERN_TYPE_BRE:
+ opt-fixed = 0;
+ opt-pcre = 0;
+ opt-regflags = ~REG_EXTENDED;
+ break;
+
+ case GREP_PATTERN_TYPE_ERE:
+ opt-fixed = 0;
+ opt-pcre = 0;
+ opt-regflags |= REG_EXTENDED;
+ break;
+
+ case GREP_PATTERN_TYPE_FIXED:
+ opt-fixed = 1;
+ opt-pcre = 0;
+ opt-regflags = ~REG_EXTENDED;
+ break;
+
+ case GREP_PATTERN_TYPE_PCRE:
+ opt-fixed = 0;
+ opt-pcre = 1;
+ opt-regflags = ~REG_EXTENDED;
+ break;
+ }
+}
+
static struct grep_pat *create_grep_pat(const char *pat, size_t patlen,
const char *origin, int no,
enum grep_pat_token t,
diff --git a/grep.h b/grep.h
index 9aa1cc7..701c784 100644
--- a/grep.h
+++ b/grep.h
@@ -141,6 +141,8 @@ struct grep_opt {
extern void init_grep_defaults(void);
extern int grep_config(const char *var, const char *value, void *);
extern void grep_init(struct grep_opt *, const char *prefix);
+void grep_set_pattern_type_option(enum grep_pattern_type, struct grep_opt
*opt);
+void grep_commit_pattern_type(enum grep_pattern_type, struct grep_opt *opt);
extern void append_grep_pat(struct grep_opt *opt, const char *pat, size_t
patlen, const char *origin, int no, enum grep_pat_token t);
extern void append_grep_pattern(struct grep_opt *opt, const
[PATCH v2 4/7] revisions: initialize revs-grep_filter using grep_init()
Instead of using the hand-rolled initialization sequence,
use grep_init() to populate the necessary bits. This opens
the door to allow the calling commands to optionally read
grep.* configuration variables via git_config() if they
want to.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
grep.c | 5 +
revision.c | 6 --
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/grep.c b/grep.c
index 279a559..a947a68 100644
--- a/grep.c
+++ b/grep.c
@@ -16,6 +16,11 @@ static struct grep_opt grep_defaults;
void init_grep_defaults(void)
{
struct grep_opt *opt = grep_defaults;
+ static int run_once;
+
+ if (run_once)
+ return;
+ run_once++;
memset(opt, 0, sizeof(*opt));
opt-relative = 1;
diff --git a/revision.c b/revision.c
index a09e60b..a4a9314 100644
--- a/revision.c
+++ b/revision.c
@@ -1048,9 +1048,9 @@ void init_revisions(struct rev_info *revs, const char
*prefix)
revs-commit_format = CMIT_FMT_DEFAULT;
+ init_grep_defaults();
+ grep_init(revs-grep_filter, prefix);
revs-grep_filter.status_only = 1;
- revs-grep_filter.pattern_tail = (revs-grep_filter.pattern_list);
- revs-grep_filter.header_tail = (revs-grep_filter.header_list);
revs-grep_filter.regflags = REG_NEWLINE;
diff_setup(revs-diffopt);
@@ -1893,6 +1893,8 @@ int setup_revisions(int argc, const char **argv, struct
rev_info *revs, struct s
revs-diffopt.abbrev = revs-abbrev;
diff_setup_done(revs-diffopt);
+ grep_commit_pattern_type(GREP_PATTERN_TYPE_UNSPECIFIED,
+revs-grep_filter);
compile_grep_patterns(revs-grep_filter);
if (revs-reverse revs-reflog_info)
--
1.8.0.rc1.76.g5a375e6
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/7] log --grep: use the same helper to set -E/-F options as git grep
The command line option parser for git log -F -E --grep='ere'
did not flip the fixed bit, violating the general last option
wins principle among conflicting options.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
revision.c | 4 ++--
t/t4202-log.sh | 6 ++
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/revision.c b/revision.c
index a4a9314..68545c8 100644
--- a/revision.c
+++ b/revision.c
@@ -1604,12 +1604,12 @@ static int handle_revision_opt(struct rev_info *revs,
int argc, const char **arg
} else if (!strcmp(arg, --grep-debug)) {
revs-grep_filter.debug = 1;
} else if (!strcmp(arg, --extended-regexp) || !strcmp(arg, -E)) {
- revs-grep_filter.regflags |= REG_EXTENDED;
+ grep_set_pattern_type_option(GREP_PATTERN_TYPE_ERE,
revs-grep_filter);
} else if (!strcmp(arg, --regexp-ignore-case) || !strcmp(arg, -i)) {
revs-grep_filter.regflags |= REG_ICASE;
DIFF_OPT_SET(revs-diffopt, PICKAXE_IGNORE_CASE);
} else if (!strcmp(arg, --fixed-strings) || !strcmp(arg, -F)) {
- revs-grep_filter.fixed = 1;
+ grep_set_pattern_type_option(GREP_PATTERN_TYPE_FIXED,
revs-grep_filter);
} else if (!strcmp(arg, --all-match)) {
revs-grep_filter.all_match = 1;
} else if ((argcount = parse_long_opt(encoding, argv, optarg))) {
diff --git a/t/t4202-log.sh b/t/t4202-log.sh
index 924ba53..e6537ab 100755
--- a/t/t4202-log.sh
+++ b/t/t4202-log.sh
@@ -230,6 +230,12 @@ test_expect_success 'log --grep -i' '
test_cmp expect actual
'
+test_expect_success 'log -F -E --grep=ere uses ere' '
+ echo second expect
+ git log -1 --pretty=tformat:%s -F -E --grep=s.c.nd actual
+ test_cmp expect actual
+'
+
cat expect EOF
* Second
* sixth
--
1.8.0.rc1.76.g5a375e6
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/7] log --grep: accept --basic-regexp and --perl-regexp
When we added the --perl-regexp option (or -P) to git grep, we
should have done the same for the commands in the git log family,
but somehow we forgot to do so. This corrects it, but we will
reserve the short-and-sweet -P option for something else for now.
Also introduce the --basic-regexp option for completeness, so that
the last one wins principle can be used to defeat an earlier -E
option, e.g. git log -E --basic-regexp --grep='bre'. Note that
it cannot have the short -G option as the option is to grep in the
patch text in the context of log family.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/rev-list-options.txt | 10 ++
revision.c | 4
2 files changed, 14 insertions(+)
diff --git a/Documentation/rev-list-options.txt
b/Documentation/rev-list-options.txt
index ee49743..1ec14a0 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -79,6 +79,11 @@ if it is part of the log message.
Match the regexp limiting patterns without regard to letters case.
+--basic-regexp::
+
+ Consider the limiting patterns to be basic regular expressions;
+ this is the default.
+
-E::
--extended-regexp::
@@ -91,6 +96,11 @@ if it is part of the log message.
Consider the limiting patterns to be fixed strings (don't interpret
pattern as a regular expression).
+--perl-regexp::
+
+ Consider the limiting patterns to be Perl-compatible regexp.
+ Requires libpcre to be compiled in.
+
--remove-empty::
Stop when a given path disappears from the tree.
diff --git a/revision.c b/revision.c
index 68545c8..d7d621c 100644
--- a/revision.c
+++ b/revision.c
@@ -1603,6 +1603,8 @@ static int handle_revision_opt(struct rev_info *revs, int
argc, const char **arg
return argcount;
} else if (!strcmp(arg, --grep-debug)) {
revs-grep_filter.debug = 1;
+ } else if (!strcmp(arg, --basic-regexp)) {
+ grep_set_pattern_type_option(GREP_PATTERN_TYPE_BRE,
revs-grep_filter);
} else if (!strcmp(arg, --extended-regexp) || !strcmp(arg, -E)) {
grep_set_pattern_type_option(GREP_PATTERN_TYPE_ERE,
revs-grep_filter);
} else if (!strcmp(arg, --regexp-ignore-case) || !strcmp(arg, -i)) {
@@ -1610,6 +1612,8 @@ static int handle_revision_opt(struct rev_info *revs, int
argc, const char **arg
DIFF_OPT_SET(revs-diffopt, PICKAXE_IGNORE_CASE);
} else if (!strcmp(arg, --fixed-strings) || !strcmp(arg, -F)) {
grep_set_pattern_type_option(GREP_PATTERN_TYPE_FIXED,
revs-grep_filter);
+ } else if (!strcmp(arg, --perl-regexp)) {
+ grep_set_pattern_type_option(GREP_PATTERN_TYPE_PCRE,
revs-grep_filter);
} else if (!strcmp(arg, --all-match)) {
revs-grep_filter.all_match = 1;
} else if ((argcount = parse_long_opt(encoding, argv, optarg))) {
--
1.8.0.rc1.76.g5a375e6
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 7/7] log: honor grep.* configuration
Now the grep_config() callback is reusable from other configuration callbacks, call it from git_log_config() so that grep.patterntype and friends can be used with the commands in the git log family. Signed-off-by: Junio C Hamano gits...@pobox.com --- builtin/log.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/builtin/log.c b/builtin/log.c index 09cf43e..e7b7db1 100644 --- a/builtin/log.c +++ b/builtin/log.c @@ -351,7 +351,8 @@ static int git_log_config(const char *var, const char *value, void *cb) } if (!prefixcmp(var, color.decorate.)) return parse_decorate_color_config(var, 15, value); - + if (grep_config(var, value, cb) 0) + return -1; return git_diff_ui_config(var, value, cb); } @@ -360,6 +361,7 @@ int cmd_whatchanged(int argc, const char **argv, const char *prefix) struct rev_info rev; struct setup_revision_opt opt; + init_grep_defaults(); git_config(git_log_config, NULL); init_revisions(rev, prefix); @@ -450,6 +452,7 @@ int cmd_show(int argc, const char **argv, const char *prefix) struct pathspec match_all; int i, count, ret = 0; + init_grep_defaults(); git_config(git_log_config, NULL); init_pathspec(match_all, NULL); @@ -530,6 +533,7 @@ int cmd_log_reflog(int argc, const char **argv, const char *prefix) struct rev_info rev; struct setup_revision_opt opt; + init_grep_defaults(); git_config(git_log_config, NULL); init_revisions(rev, prefix); @@ -552,6 +556,7 @@ int cmd_log(int argc, const char **argv, const char *prefix) struct rev_info rev; struct setup_revision_opt opt; + init_grep_defaults(); git_config(git_log_config, NULL); init_revisions(rev, prefix); @@ -1121,6 +1126,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix) extra_hdr.strdup_strings = 1; extra_to.strdup_strings = 1; extra_cc.strdup_strings = 1; + init_grep_defaults(); git_config(git_format_config, NULL); init_revisions(rev, prefix); rev.commit_format = CMIT_FMT_EMAIL; -- 1.8.0.rc1.76.g5a375e6 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git checkout error
Hi Junio It is not difficult. The discussion on this list is usually done via patches, and without one, constant talking is buried in other noise and often go unnoticed. Could you accept for very small changes also the simple indication of the change itself instead of a patch? There is however an issue about documentation consistency. Do we use elsewhere ( A | B | C ... ) to denote You must write one (and only one) among A, B, C, ... consistently in the documentation? There is no standard for it. Posix provides a standard for commands: http://pubs.opengroup.org/onlinepubs/9699919799/ but does not mention (normal) parentheses to indicate choice. There is one applicable standard for this, though, the ISO 14977: http://www.cl.cam.ac.uk/~mgk25/iso-14977.pdf which gives parentheses () the meaning of grouping (and then with | inside them, the meaning of choice). Parentheses are used in: - git branch - git commit - git reset - git remote - git submodule - git bisect - git grep - git am - git apply - git format-patch - git cat-file - git commit-tree - git rev-list - git update-index I did not find in the documentation an explanation of the use of parentheses, but to me they seem to have been used consistently. -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: username case conflict in git svn clone [SOLVED]
Gah! Schoolboy error. juser = Joe User joe.u...@example.com Thanks for the pointer! Cheers, Dave. -Original Message- From: Andreas Schwab [mailto:sch...@linux-m68k.org] Sent: 09 October 2012 19:03 To: Balch, David Cc: git@vger.kernel.org Subject: Re: username case conflict in git svn clone David Balch david.ba...@conted.ox.ac.uk writes: whenusers.txt contains: juser Joe User joe.u...@example.com JUser Joe User joe.u...@example.com Reread the manual. Hint: there must be an equal sign. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] format-patch: do not wrap rfc2047 encoded headers too late
Am 09.10.2012 21:30, schrieb Junio C Hamano:
Jan H. Schönherr schn...@cs.tu-berlin.de writes:
...
static int is_rfc2047_special(char ch)
{
+/*
+ * We encode ' ' using '=20' even though rfc2047
+ * allows using '_' for readability. Unfortunately,
+ * many programs do not understand this and just
+ * leave the underscore in place.
+ */
The sentence break made me read the above three times to understand
what it is trying to say. Unfortunately refers to what happens if
we were to use '_', but it initially appeared to be describing some
bug due to our encoding ' ' as '=20'. Perhaps like this?
/*
* rfc2047 allows '_' to encode ' ' for readability, but
* many programs do not understand ...; encode ' ' using
* '=20' instead to avoid the problem.
*/
I was just moving that comment (and the following check) around,
but I'll update the comment in the next version.
+if (ch == ' ' || ch == '\n')
+return 1;
The comment justifies why this if (ch == ' '), which could be part
of the return below, separately is done, but nothing explains why
you add '\n' (and not other controls, e.g. '\t') to the mix.
The check for '\n' was introduced in commit c22e7de3
(format-patch: rfc2047-encode newlines in headers).
The commit log was:
These should generally never happen, as we already
concatenate multiples in subjects into a single line. But
let's be defensive, since not encoding them means we will
output malformed headers.
Having again a look at RFC 2047, I see that we should be
even more strict and not allow any non-printable character to
be passed through unencoded. I guess that adds another patch to
the series. Hmm... Maybe I can split patch 4 into two patches,
one that mostly fixes is_rfc2047_special() and one that
avoids 822 quoting when doing 2047 encoding.
return (non_ascii(ch) || (ch == '=') || (ch == '?') || (ch == '_'));
}
static void add_rfc2047(struct strbuf *sb, const char *line, int len,
const char *encoding)
{
-static const int max_length = 78; /* per rfc2822 */
+static const int max_length = 76; /* per rfc2047 */
int i;
int line_len;
@@ -286,7 +295,7 @@ static void add_rfc2047(struct strbuf *sb, const char
*line, int len,
if ((i + 1 len) (ch == '=' line[i+1] == '?'))
goto needquote;
}
-strbuf_add_wrapped_bytes(sb, line, len, -line_len, 1, max_length+1);
+strbuf_add_wrapped_bytes(sb, line, len, -line_len, 1, 78+1);
return;
Yuck. If you do want to retain 78 for non-quoted output for
backward compatibility, that is OK, but if that is the case, please
introduce a new constant max_quoted_length or something to stand
for 76 and use it in the needquote: part below.
Will do.
Regards
Jan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] attr: more matching optimizations from .gitignore
.gitattributes and .gitignore share the same pattern syntax but has
separate matching implementation. Over the years, ignore's
implementation accumulates more optimizations while attr's stays the
same.
This patch adds those optimizations to attr. Basically it tries to
avoid fnmatch as much as possible in favor of strncmp.
A few notes from this work is put in the documentation:
* !pattern syntax is not supported in .gitattributes as it's not
clear what it means (e.g. !path attr is about unsetting attr, or
undefining it..)
* patterns applying to directories
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
How about this? Diff from the previous version:
diff --git a/Documentation/gitattributes.txt
b/Documentation/gitattributes.txt
index cc2ff1d..9a0ed19 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -23,7 +23,7 @@ Each line in `gitattributes` file is of form:
That is, a pattern followed by an attributes list,
separated by whitespaces. When the pattern matches the
path in question, the attributes listed on the line are given to
-the path. Only files can be attached attributes to.
+the path.
Each attribute can be in one of these states for a given path:
@@ -58,6 +58,13 @@ attribute. The rules how the pattern matches paths are
the
same as in `.gitignore` files; see linkgit:gitignore[5].
Unlike `.gitignore`, negative patterns are not supported.
+Note that if a .gitignore rule matches a directory, the directory
+is ignored, which may be seen as assigning ignore attribute the
+directory and all files and directories inside. However, if a
+.gitattributes rule matches a directory, it manipulates
+attributes on that directory only, not files and directories
+inside.
+
When deciding what attributes are assigned to a path, git
consults `$GIT_DIR/info/attributes` file (which has the highest
precedence), `.gitattributes` file in the same directory as the
diff --git a/attr.c b/attr.c
index 7e85f82..4faf1ff 100644
--- a/attr.c
+++ b/attr.c
@@ -250,7 +250,6 @@ static struct match_attr *parse_attr_line(const char
*line, const char *src,
else {
char *p = (char *)(res-state[num_attr]);
memcpy(p, name, namelen);
-p[namelen] = 0;
res-u.pat.pattern = p;
parse_exclude_pattern(res-u.pat.pattern,
res-u.pat.patternlen,
@@ -690,16 +689,18 @@ static int path_matches(const char *pathname, int
pathlen,
* contain the trailing slash
*/
-if (pathlen baselen ||
+if (pathlen baselen + 1 ||
(baselen pathname[baselen] != '/') ||
-strncmp(pathname, base, baselen))
+strncmp_icase(pathname, base, baselen))
return 0;
namelen = baselen ? pathlen - baselen - 1 : pathlen;
name = pathname + pathlen - namelen;
-/* if the non-wildcard part is longer than the remaining
- pathname, surely it cannot match */
+/*
+ * if the non-wildcard part is longer than the remaining
+ * pathname, surely it cannot match
+ */
if (!namelen || prefix namelen)
return 0;
Documentation/gitattributes.txt | 8 +
attr.c | 72 +
dir.c | 8 ++---
dir.h | 1 +
t/t0003-attributes.sh | 14
5 files changed, 86 insertions(+), 17 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 80120ea..9a0ed19 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -56,6 +56,14 @@ When more than one pattern matches the path, a later line
overrides an earlier line. This overriding is done per
attribute. The rules how the pattern matches paths are the
same as in `.gitignore` files; see linkgit:gitignore[5].
+Unlike `.gitignore`, negative patterns are not supported.
+
+Note that if a .gitignore rule matches a directory, the directory
+is ignored, which may be seen as assigning ignore attribute the
+directory and all files and directories inside. However, if a
+.gitattributes rule matches a directory, it manipulates
+attributes on that directory only, not files and directories
+inside.
When deciding what attributes are assigned to a path, git
consults `$GIT_DIR/info/attributes` file (which has the highest
diff --git a/attr.c b/attr.c
index e7caee4..4faf1ff 100644
--- a/attr.c
+++ b/attr.c
@@ -115,6 +115,13 @@ struct attr_state {
const char *setto;
};
+struct pattern {
+ const char *pattern;
+ int patternlen;
+ int nowildcardlen;
+ int flags; /* EXC_FLAG_* */
+};
+
/*
* One rule, as from a .gitattributes file.
*
@@ -131,7 +138,7 @@ struct
[PATCH v4 00/12] Wildmatch v4
Really small updates. I did not want to resend it this soon but this may fix the compile errors for Junio. Changes are - cleanup in wildmatch.c so #include cache.h is at the top of the file. - wildmatch() returns no match if it encounters ** without surrounding slashes. It returns a special code so we can actually show a warning at higher level. I don't want to do that now because I want to mark the pattern broken in attr.c/dir.c so the pattern will never be used again, and the message shown only once. That needs nd/attr-match-optim-more, but I don't want to tie this series to that just yet. Nguyễn Thái Ngọc Duy (12): ctype: make sane_ctype[] const array ctype: support iscntrl, ispunct, isxdigit and isprint Import wildmatch from rsync wildmatch: remove unnecessary functions Integrate wildmatch to git wildmatch: make wildmatch's return value compatible with fnmatch wildmatch: remove static variable force_lower_case wildmatch: fix case-insensitive matching wildmatch: adjust ** behavior wildmatch: make /**/ match zero or more directories Support ** wildcard in .gitignore and .gitattributes t3070: disable two fnmatch tests that have different results on different libc .gitignore | 1 + Documentation/gitattributes.txt| 6 + Documentation/gitignore.txt| 19 +++ Makefile | 3 + attr.c | 4 +- ctype.c| 20 +++- dir.c | 4 +- git-compat-util.h | 15 ++- t/t0003-attributes.sh | 38 ++ t/t3001-ls-files-others-exclude.sh | 19 +++ t/t3070-wildmatch.sh | 187 + test-wildmatch.c | 14 +++ wildmatch.c| 240 + wildmatch.h| 9 ++ 14 files changed, 575 insertions(+), 4 deletions(-) create mode 100755 t/t3070-wildmatch.sh create mode 100644 test-wildmatch.c create mode 100644 wildmatch.c create mode 100644 wildmatch.h -- 1.7.12.1.406.g6ab07c4 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 01/12] ctype: make sane_ctype[] const array
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
ctype.c | 2 +-
git-compat-util.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/ctype.c b/ctype.c
index 9353271..faeaf34 100644
--- a/ctype.c
+++ b/ctype.c
@@ -14,7 +14,7 @@ enum {
P = GIT_PATHSPEC_MAGIC /* other non-alnum, except for ] and } */
};
-unsigned char sane_ctype[256] = {
+const unsigned char sane_ctype[256] = {
0, 0, 0, 0, 0, 0, 0, 0, 0, S, S, 0, 0, S, 0, 0, /* 0.. 15 */
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* 16.. 31 */
S, P, P, P, R, P, P, P, R, R, G, R, P, P, R, P, /* 32.. 47 */
diff --git a/git-compat-util.h b/git-compat-util.h
index 2fbf1fd..f8b859c 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -510,7 +510,7 @@ extern const char tolower_trans_tbl[256];
#undef isupper
#undef tolower
#undef toupper
-extern unsigned char sane_ctype[256];
+extern const unsigned char sane_ctype[256];
#define GIT_SPACE 0x01
#define GIT_DIGIT 0x02
#define GIT_ALPHA 0x04
--
1.7.12.1.406.g6ab07c4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 02/12] ctype: support iscntrl, ispunct, isxdigit and isprint
A new table sane_ctype2[] is added, otherwise we'll need to OR with
current bits in sane_ctype[] and that looks ugly.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
ctype.c | 18 ++
git-compat-util.h | 13 +
2 files changed, 31 insertions(+)
diff --git a/ctype.c b/ctype.c
index faeaf34..b4bf48a 100644
--- a/ctype.c
+++ b/ctype.c
@@ -26,6 +26,24 @@ const unsigned char sane_ctype[256] = {
/* Nothing in the 128.. range */
};
+enum {
+ CN = GIT_CNTRL,
+ PU = GIT_PUNCT,
+ XD = GIT_XDIGIT,
+};
+
+const unsigned char sane_ctype2[256] = {
+ CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, /*
0..15 */
+ CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, /*
16..31 */
+ 0, PU, PU, PU, PU, PU, PU, PU, PU, PU, PU, PU, PU, PU, PU, PU, /*
32..47 */
+ XD, XD, XD, XD, XD, XD, XD, XD, XD, XD, PU, PU, PU, PU, PU, PU, /*
48..63 */
+ PU, 0, XD, 0, XD, 0, XD, 0, 0, 0, 0, 0, 0, 0, 0, 0, /*
64..79 */
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, PU, PU, PU, PU, PU, /*
80..95 */
+ PU, 0, XD, 0, XD, 0, XD, 0, 0, 0, 0, 0, 0, 0, 0, 0, /*
96..111 */
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, PU, PU, PU, PU, CN, /*
112..127 */
+ /* Nothing in the 128.. range */
+};
+
/* For case-insensitive kwset */
const char tolower_trans_tbl[256] = {
0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
diff --git a/git-compat-util.h b/git-compat-util.h
index f8b859c..ea11694 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -510,14 +510,23 @@ extern const char tolower_trans_tbl[256];
#undef isupper
#undef tolower
#undef toupper
+#undef iscntrl
+#undef ispunct
+#undef isxdigit
+#undef isprint
extern const unsigned char sane_ctype[256];
+extern const unsigned char sane_ctype2[256];
#define GIT_SPACE 0x01
#define GIT_DIGIT 0x02
#define GIT_ALPHA 0x04
#define GIT_GLOB_SPECIAL 0x08
#define GIT_REGEX_SPECIAL 0x10
#define GIT_PATHSPEC_MAGIC 0x20
+#define GIT_CNTRL 0x01
+#define GIT_PUNCT 0x02
+#define GIT_XDIGIT 0x04
#define sane_istest(x,mask) ((sane_ctype[(unsigned char)(x)] (mask)) != 0)
+#define sane_istest2(x,mask) ((sane_ctype2[(unsigned char)(x)] (mask)) != 0)
#define isascii(x) (((x) ~0x7f) == 0)
#define isspace(x) sane_istest(x,GIT_SPACE)
#define isdigit(x) sane_istest(x,GIT_DIGIT)
@@ -527,6 +536,10 @@ extern const unsigned char sane_ctype[256];
#define isupper(x) sane_iscase(x, 0)
#define is_glob_special(x) sane_istest(x,GIT_GLOB_SPECIAL)
#define is_regex_special(x) sane_istest(x,GIT_GLOB_SPECIAL | GIT_REGEX_SPECIAL)
+#define iscntrl(x) sane_istest2(x, GIT_CNTRL)
+#define ispunct(x) sane_istest2(x, GIT_PUNCT)
+#define isxdigit(x) sane_istest2(x, GIT_XDIGIT)
+#define isprint(x) (isalnum(x) || isspace(x) || ispunct(x))
#define tolower(x) sane_case((unsigned char)(x), 0x20)
#define toupper(x) sane_case((unsigned char)(x), 0)
#define is_pathspec_magic(x) sane_istest(x,GIT_PATHSPEC_MAGIC)
--
1.7.12.1.406.g6ab07c4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 03/12] Import wildmatch from rsync
These files are from rsync.git commit f92f5b166e3019db42bc7fe1aa2f1a9178cd215d, which was the last commit before rsync turned GPL-3. All files are imported as-is and no-op. Adaptation is done in a separate patch. rsync.git - git.git lib/wildmatch.[ch] wildmatch.[ch] wildtest.txtt/t3070/wildtest.txt Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- t/t3070/wildtest.txt | 165 +++ wildmatch.c | 368 +++ wildmatch.h | 6 + 3 files changed, 539 insertions(+) create mode 100644 t/t3070/wildtest.txt create mode 100644 wildmatch.c create mode 100644 wildmatch.h diff --git a/t/t3070/wildtest.txt b/t/t3070/wildtest.txt new file mode 100644 index 000..42c1678 --- /dev/null +++ b/t/t3070/wildtest.txt @@ -0,0 +1,165 @@ +# Input is in the following format (all items white-space separated): +# +# The first two items are 1 or 0 indicating if the wildmat call is expected to +# succeed and if fnmatch works the same way as wildmat, respectively. After +# that is a text string for the match, and a pattern string. Strings can be +# quoted (if desired) in either double or single quotes, as well as backticks. +# +# MATCH FNMATCH_SAME text to match 'pattern to use' + +# Basic wildmat features +1 1 foofoo +0 1 foobar +1 1 '' +1 1 foo??? +0 1 foo?? +1 1 foo* +1 1 foof* +0 1 foo*f +1 1 foo*foo* +1 1 foobar *ob*a*r* +1 1 aaabababab *ab +1 1 foo* foo\* +0 1 foobar foo\*bar +1 1 f\oo f\\oo +1 1 ball *[al]? +0 1 ten[ten] +1 1 ten**[!te] +0 1 ten**[!ten] +1 1 tent[a-g]n +0 1 tent[!a-g]n +1 1 tont[!a-g]n +1 1 tont[^a-g]n +1 1 a]ba[]]b +1 1 a-ba[]-]b +1 1 a]ba[]-]b +0 1 aaba[]-]b +1 1 aaba[]a-]b +1 1 ] ] + +# Extended slash-matching features +0 1 foo/baz/barfoo*bar +1 1 foo/baz/barfoo**bar +0 1 foo/barfoo?bar +0 1 foo/barfoo[/]bar +0 1 foo/barf[^eiu][^eiu][^eiu][^eiu][^eiu]r +1 1 foo-barf[^eiu][^eiu][^eiu][^eiu][^eiu]r +0 1 foo**/foo +1 1 /foo **/foo +1 1 bar/baz/foo**/foo +0 1 bar/baz/foo*/foo +0 0 foo/bar/baz**/bar* +1 1 deep/foo/bar/baz **/bar/* +0 1 deep/foo/bar/baz/ **/bar/* +1 1 deep/foo/bar/baz/ **/bar/** +0 1 deep/foo/bar **/bar/* +1 1 deep/foo/bar/ **/bar/** +1 1 foo/bar/baz**/bar** +1 1 foo/bar/baz/x */bar/** +0 0 deep/foo/bar/baz/x */bar/** +1 1 deep/foo/bar/baz/x **/bar/*/* + +# Various additional tests +0 1 acrt a[c-c]st +1 1 acrt a[c-c]rt +0 1 ] [!]-] +1 1 a [!]-] +0 1 '' \ +0 1 \ \ +0 1 /\ */\ +1 1 /\ */\\ +1 1 foofoo +1 1 @foo @foo +0 1 foo@foo +1 1 [ab] \[ab] +1 1 [ab] [[]ab] +1 1 [ab] [[:]ab] +0 1 [ab] [[::]ab] +1 1 [ab] [[:digit]ab] +1 1 [ab] [\[:]ab] +1 1 ?a?b \??\?b +1 1 abc\a\b\c +0 1 foo'' +1 1 foo/bar/baz/to **/t[o] + +# Character class tests +1 1 a1B[[:alpha:]][[:digit:]][[:upper:]] +0 1 a [[:digit:][:upper:][:space:]] +1 1 A [[:digit:][:upper:][:space:]] +1 1 1 [[:digit:][:upper:][:space:]] +0 1 1 [[:digit:][:upper:][:spaci:]] +1 1 ' '[[:digit:][:upper:][:space:]] +0 1 . [[:digit:][:upper:][:space:]] +1 1 . [[:digit:][:punct:][:space:]] +1 1 5 [[:xdigit:]] +1 1 f [[:xdigit:]] +1 1 D [[:xdigit:]] +1 1 _ [[:alnum:][:alpha:][:blank:][:cntrl:][:digit:][:graph:][:lower:][:print:][:punct:][:space:][:upper:][:xdigit:]] +#1 1 � [^[:alnum:][:alpha:][:blank:][:cntrl:][:digit:][:graph:][:lower:][:print:][:punct:][:space:][:upper:][:xdigit:]] +1 1 [^[:alnum:][:alpha:][:blank:][:digit:][:graph:][:lower:][:print:][:punct:][:space:][:upper:][:xdigit:]] +1 1 . [^[:alnum:][:alpha:][:blank:][:cntrl:][:digit:][:lower:][:space:][:upper:][:xdigit:]] +1 1 5 [a-c[:digit:]x-z] +1 1 b [a-c[:digit:]x-z] +1 1 y [a-c[:digit:]x-z] +0 1 q [a-c[:digit:]x-z] + +# Additional tests, including some malformed wildmats
[PATCH v4 04/12] wildmatch: remove unnecessary functions
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
wildmatch.c | 161
wildmatch.h | 2 -
2 files changed, 9 insertions(+), 154 deletions(-)
diff --git a/wildmatch.c b/wildmatch.c
index f3a1731..71dba76 100644
--- a/wildmatch.c
+++ b/wildmatch.c
@@ -53,33 +53,19 @@
#define ISUPPER(c) (ISASCII(c) isupper(c))
#define ISXDIGIT(c) (ISASCII(c) isxdigit(c))
-#ifdef WILD_TEST_ITERATIONS
-int wildmatch_iteration_count;
-#endif
-
static int force_lower_case = 0;
/* Match pattern p against the a virtually-joined string consisting
* of text and any strings in array a. */
-static int dowild(const uchar *p, const uchar *text, const uchar*const *a)
+static int dowild(const uchar *p, const uchar *text)
{
uchar p_ch;
-#ifdef WILD_TEST_ITERATIONS
-wildmatch_iteration_count++;
-#endif
-
for ( ; (p_ch = *p) != '\0'; text++, p++) {
int matched, special;
uchar t_ch, prev_ch;
- while ((t_ch = *text) == '\0') {
- if (*a == NULL) {
- if (p_ch != '*')
- return ABORT_ALL;
- break;
- }
- text = *a++;
- }
+ if ((t_ch = *text) == '\0' p_ch != '*')
+ return ABORT_ALL;
if (force_lower_case ISUPPER(t_ch))
t_ch = tolower(t_ch);
switch (p_ch) {
@@ -107,21 +93,15 @@ static int dowild(const uchar *p, const uchar *text, const
uchar*const *a)
/* Trailing ** matches everything. Trailing * matches
* only if there are no more slash characters. */
if (!special) {
- do {
if (strchr((char*)text, '/') != NULL)
return FALSE;
- } while ((text = *a++) != NULL);
}
return TRUE;
}
while (1) {
- if (t_ch == '\0') {
- if ((text = *a++) == NULL)
- break;
- t_ch = *text;
- continue;
- }
- if ((matched = dowild(p, text, a)) != FALSE) {
+ if (t_ch == '\0')
+ break;
+ if ((matched = dowild(p, text)) != FALSE) {
if (!special || matched != ABORT_TO_STARSTAR)
return matched;
} else if (!special t_ch == '/')
@@ -225,144 +205,21 @@ static int dowild(const uchar *p, const uchar *text,
const uchar*const *a)
}
}
-do {
- if (*text)
- return FALSE;
-} while ((text = *a++) != NULL);
-
-return TRUE;
-}
-
-/* Match literal string s against the a virtually-joined string consisting
- * of text and any strings in array a. */
-static int doliteral(const uchar *s, const uchar *text, const uchar*const *a)
-{
-for ( ; *s != '\0'; text++, s++) {
- while (*text == '\0') {
- if ((text = *a++) == NULL)
- return FALSE;
- }
- if (*text != *s)
- return FALSE;
-}
-
-do {
- if (*text)
- return FALSE;
-} while ((text = *a++) != NULL);
-
-return TRUE;
-}
-
-/* Return the last count path elements from the concatenated string.
- * We return a string pointer to the start of the string, and update the
- * array pointer-pointer to point to any remaining string elements. */
-static const uchar *trailing_N_elements(const uchar*const **a_ptr, int count)
-{
-const uchar*const *a = *a_ptr;
-const uchar*const *first_a = a;
-
-while (*a)
- a++;
-
-while (a != first_a) {
- const uchar *s = *--a;
- s += strlen((char*)s);
- while (--s = *a) {
- if (*s == '/' !--count) {
- *a_ptr = a+1;
- return s+1;
- }
- }
-}
-
-if (count == 1) {
- *a_ptr = a+1;
- return *a;
-}
-
-return NULL;
+return *text ? FALSE : TRUE;
}
/* Match the pattern against the text string. */
int wildmatch(const char *pattern, const char *text)
{
-static const uchar *nomore[1]; /* A NULL pointer. */
-#ifdef WILD_TEST_ITERATIONS
-wildmatch_iteration_count = 0;
-#endif
-return dowild((const uchar*)pattern, (const uchar*)text, nomore) == TRUE;
+return dowild((const uchar*)pattern, (const uchar*)text) == TRUE;
}
/* Match the pattern against the forced-to-lower-case text string. */
int iwildmatch(const char *pattern, const char *text)
{
-static const uchar *nomore[1]; /* A NULL pointer. */
int ret;
-#ifdef WILD_TEST_ITERATIONS
-wildmatch_iteration_count = 0;
-#endif
force_lower_case = 1;
-ret = dowild((const uchar*)pattern, (const uchar*)text, nomore) == TRUE;
+ret = dowild((const uchar*)pattern, (const uchar*)text) == TRUE;
force_lower_case = 0;
return ret;
}
-
-/* Match pattern p against the a virtually-joined string consisting
- * of all the pointers in array
[PATCH v4 05/12] Integrate wildmatch to git
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
.gitignore | 1 +
Makefile | 3 +
t/t3070-wildmatch.sh | 178 +++
t/t3070/wildtest.txt | 165 ---
test-wildmatch.c | 14
wildmatch.c | 5 +-
6 files changed, 200 insertions(+), 166 deletions(-)
create mode 100755 t/t3070-wildmatch.sh
delete mode 100644 t/t3070/wildtest.txt
create mode 100644 test-wildmatch.c
diff --git a/.gitignore b/.gitignore
index a188a82..37c3507 100644
--- a/.gitignore
+++ b/.gitignore
@@ -197,6 +197,7 @@
/test-string-list
/test-subprocess
/test-svn-fe
+/test-wildmatch
/common-cmds.h
*.tar.gz
*.dsc
diff --git a/Makefile b/Makefile
index 8413606..9a97379 100644
--- a/Makefile
+++ b/Makefile
@@ -523,6 +523,7 @@ TEST_PROGRAMS_NEED_X += test-sigchain
TEST_PROGRAMS_NEED_X += test-string-list
TEST_PROGRAMS_NEED_X += test-subprocess
TEST_PROGRAMS_NEED_X += test-svn-fe
+TEST_PROGRAMS_NEED_X += test-wildmatch
TEST_PROGRAMS = $(patsubst %,%$X,$(TEST_PROGRAMS_NEED_X))
@@ -695,6 +696,7 @@ LIB_H += userdiff.h
LIB_H += utf8.h
LIB_H += varint.h
LIB_H += walker.h
+LIB_H += wildmatch.h
LIB_H += wt-status.h
LIB_H += xdiff-interface.h
LIB_H += xdiff/xdiff.h
@@ -826,6 +828,7 @@ LIB_OBJS += utf8.o
LIB_OBJS += varint.o
LIB_OBJS += version.o
LIB_OBJS += walker.o
+LIB_OBJS += wildmatch.o
LIB_OBJS += wrapper.o
LIB_OBJS += write_or_die.o
LIB_OBJS += ws.o
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
new file mode 100755
index 000..bb92f8d
--- /dev/null
+++ b/t/t3070-wildmatch.sh
@@ -0,0 +1,178 @@
+#!/bin/sh
+
+test_description='wildmatch tests'
+
+. ./test-lib.sh
+
+match() {
+test_expect_success wildmatch $*
+ if [ $1 = 1 ]; then
+ test-wildmatch wildmatch '$3' '$4'
+ else
+ ! test-wildmatch wildmatch '$3' '$4'
+ fi
+ if [ $2 = 1 ]; then
+ test-wildmatch fnmatch '$3' '$4'
+ else
+ ! test-wildmatch fnmatch '$3' '$4'
+ fi
+
+}
+
+# Basic wildmat features
+match 1 1 foo foo
+match 0 0 foo bar
+match 1 1 ''
+match 1 1 foo '???'
+match 0 0 foo '??'
+match 1 1 foo '*'
+match 1 1 foo 'f*'
+match 0 0 foo '*f'
+match 1 1 foo '*foo*'
+match 1 1 foobar '*ob*a*r*'
+match 1 1 aaabababab '*ab'
+match 1 1 'foo*' 'foo\*'
+match 0 0 foobar 'foo\*bar'
+match 1 1 'f\oo' 'f\\oo'
+match 1 1 ball '*[al]?'
+match 0 0 ten '[ten]'
+match 1 1 ten '**[!te]'
+match 0 0 ten '**[!ten]'
+match 1 1 ten 't[a-g]n'
+match 0 0 ten 't[!a-g]n'
+match 1 1 ton 't[!a-g]n'
+match 1 1 ton 't[^a-g]n'
+match 1 1 'a]b' 'a[]]b'
+match 1 1 a-b 'a[]-]b'
+match 1 1 'a]b' 'a[]-]b'
+match 0 0 aab 'a[]-]b'
+match 1 1 aab 'a[]a-]b'
+match 1 1 ']' ']'
+
+# Extended slash-matching features
+match 0 0 'foo/baz/bar' 'foo*bar'
+match 1 0 'foo/baz/bar' 'foo**bar'
+match 0 0 'foo/bar' 'foo?bar'
+match 0 0 'foo/bar' 'foo[/]bar'
+match 0 0 'foo/bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
+match 1 1 'foo-bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
+match 0 0 'foo' '**/foo'
+match 1 1 '/foo' '**/foo'
+match 1 0 'bar/baz/foo' '**/foo'
+match 0 0 'bar/baz/foo' '*/foo'
+match 0 0 'foo/bar/baz' '**/bar*'
+match 1 0 'deep/foo/bar/baz' '**/bar/*'
+match 0 0 'deep/foo/bar/baz/' '**/bar/*'
+match 1 0 'deep/foo/bar/baz/' '**/bar/**'
+match 0 0 'deep/foo/bar' '**/bar/*'
+match 1 0 'deep/foo/bar/' '**/bar/**'
+match 1 0 'foo/bar/baz' '**/bar**'
+match 1 0 'foo/bar/baz/x' '*/bar/**'
+match 0 0 'deep/foo/bar/baz/x' '*/bar/**'
+match 1 0 'deep/foo/bar/baz/x' '**/bar/*/*'
+
+# Various additional tests
+match 0 0 'acrt' 'a[c-c]st'
+match 1 1 'acrt' 'a[c-c]rt'
+match 0 0 ']' '[!]-]'
+match 1 1 'a' '[!]-]'
+match 0 0 '' '\'
+match 0 0 '\' '\'
+match 0 0 '/\' '*/\'
+match 1 1 '/\' '*/\\'
+match 1 1 'foo' 'foo'
+match 1 1 '@foo' '@foo'
+match 0 0 'foo' '@foo'
+match 1 1 '[ab]' '\[ab]'
+match 1 1 '[ab]' '[[]ab]'
+match 1 1 '[ab]' '[[:]ab]'
+match 0 0 '[ab]' '[[::]ab]'
+match 1 1 '[ab]' '[[:digit]ab]'
+match 1 1 '[ab]' '[\[:]ab]'
+match 1 1 '?a?b' '\??\?b'
+match 1 1 'abc' '\a\b\c'
+match 0 0 'foo' ''
+match 1 0 'foo/bar/baz/to' '**/t[o]'
+
+# Character class tests
+match 1 1 'a1B' '[[:alpha:]][[:digit:]][[:upper:]]'
+match 0 0 'a' '[[:digit:][:upper:][:space:]]'
+match 1 1 'A' '[[:digit:][:upper:][:space:]]'
+match 1 0 '1' '[[:digit:][:upper:][:space:]]'
+match 0 0 '1' '[[:digit:][:upper:][:spaci:]]'
+match 1 1 ' ' '[[:digit:][:upper:][:space:]]'
+match 0 0 '.' '[[:digit:][:upper:][:space:]]'
+match 1 1 '.' '[[:digit:][:punct:][:space:]]'
+match 1 1 '5' '[[:xdigit:]]'
+match 1 1 'f' '[[:xdigit:]]'
+match 1 1 'D' '[[:xdigit:]]'
+match 1 0 '_'
'[[:alnum:][:alpha:][:blank:][:cntrl:][:digit:][:graph:][:lower:][:print:][:punct:][:space:][:upper:][:xdigit:]]'
+match 1 0 '_'
'[[:alnum:][:alpha:][:blank:][:cntrl:][:digit:][:graph:][:lower:][:print:][:punct:][:space:][:upper:][:xdigit:]]'
+match 1 1 '.'
[PATCH v4 06/12] wildmatch: make wildmatch's return value compatible with fnmatch
wildmatch returns non-zero if matched, zero otherwise. This patch
makes it return zero if matches, non-zero otherwise, like fnmatch().
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
test-wildmatch.c | 4 ++--
wildmatch.c | 21 -
2 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/test-wildmatch.c b/test-wildmatch.c
index 08962d5..596029c 100644
--- a/test-wildmatch.c
+++ b/test-wildmatch.c
@@ -4,9 +4,9 @@
int main(int argc, char **argv)
{
if (!strcmp(argv[1], wildmatch))
- return wildmatch(argv[3], argv[2]) ? 0 : 1;
+ return wildmatch(argv[3], argv[2]);
else if (!strcmp(argv[1], iwildmatch))
- return iwildmatch(argv[3], argv[2]) ? 0 : 1;
+ return iwildmatch(argv[3], argv[2]);
else if (!strcmp(argv[1], fnmatch))
return fnmatch(argv[3], argv[2], FNM_PATHNAME);
else
diff --git a/wildmatch.c b/wildmatch.c
index 6092bde..7c180e3 100644
--- a/wildmatch.c
+++ b/wildmatch.c
@@ -20,6 +20,9 @@ typedef unsigned char uchar;
#define FALSE 0
#define TRUE 1
+
+#define NOMATCH 1
+#define MATCH 0
#define ABORT_ALL -1
#define ABORT_TO_STARSTAR -2
@@ -79,12 +82,12 @@ static int dowild(const uchar *p, const uchar *text)
/* FALLTHROUGH */
default:
if (t_ch != p_ch)
- return FALSE;
+ return NOMATCH;
continue;
case '?':
/* Match anything but '/'. */
if (t_ch == '/')
- return FALSE;
+ return NOMATCH;
continue;
case '*':
if (*++p == '*') {
@@ -97,14 +100,14 @@ static int dowild(const uchar *p, const uchar *text)
* only if there are no more slash characters. */
if (!special) {
if (strchr((char*)text, '/') != NULL)
- return FALSE;
+ return NOMATCH;
}
- return TRUE;
+ return MATCH;
}
while (1) {
if (t_ch == '\0')
break;
- if ((matched = dowild(p, text)) != FALSE) {
+ if ((matched = dowild(p, text)) != NOMATCH) {
if (!special || matched != ABORT_TO_STARSTAR)
return matched;
} else if (!special t_ch == '/')
@@ -203,18 +206,18 @@ static int dowild(const uchar *p, const uchar *text)
matched = TRUE;
} while (prev_ch = p_ch, (p_ch = *++p) != ']');
if (matched == special || t_ch == '/')
- return FALSE;
+ return NOMATCH;
continue;
}
}
-return *text ? FALSE : TRUE;
+return *text ? NOMATCH : MATCH;
}
/* Match the pattern against the text string. */
int wildmatch(const char *pattern, const char *text)
{
-return dowild((const uchar*)pattern, (const uchar*)text) == TRUE;
+return dowild((const uchar*)pattern, (const uchar*)text);
}
/* Match the pattern against the forced-to-lower-case text string. */
@@ -222,7 +225,7 @@ int iwildmatch(const char *pattern, const char *text)
{
int ret;
force_lower_case = 1;
-ret = dowild((const uchar*)pattern, (const uchar*)text) == TRUE;
+ret = dowild((const uchar*)pattern, (const uchar*)text);
force_lower_case = 0;
return ret;
}
--
1.7.12.1.406.g6ab07c4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 07/12] wildmatch: remove static variable force_lower_case
One place less to worry about thread safety. Also combine wildmatch
and iwildmatch into one.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
test-wildmatch.c | 4 ++--
wildmatch.c | 21 +
wildmatch.h | 3 +--
3 files changed, 8 insertions(+), 20 deletions(-)
diff --git a/test-wildmatch.c b/test-wildmatch.c
index 596029c..d716852 100644
--- a/test-wildmatch.c
+++ b/test-wildmatch.c
@@ -4,9 +4,9 @@
int main(int argc, char **argv)
{
if (!strcmp(argv[1], wildmatch))
- return wildmatch(argv[3], argv[2]);
+ return wildmatch(argv[3], argv[2], 0);
else if (!strcmp(argv[1], iwildmatch))
- return iwildmatch(argv[3], argv[2]);
+ return wildmatch(argv[3], argv[2], FNM_CASEFOLD);
else if (!strcmp(argv[1], fnmatch))
return fnmatch(argv[3], argv[2], FNM_PATHNAME);
else
diff --git a/wildmatch.c b/wildmatch.c
index 7c180e3..d18d721 100644
--- a/wildmatch.c
+++ b/wildmatch.c
@@ -59,11 +59,9 @@ typedef unsigned char uchar;
#define ISUPPER(c) (ISASCII(c) isupper(c))
#define ISXDIGIT(c) (ISASCII(c) isxdigit(c))
-static int force_lower_case = 0;
-
/* Match pattern p against the a virtually-joined string consisting
* of text and any strings in array a. */
-static int dowild(const uchar *p, const uchar *text)
+static int dowild(const uchar *p, const uchar *text, int force_lower_case)
{
uchar p_ch;
@@ -107,7 +105,7 @@ static int dowild(const uchar *p, const uchar *text)
while (1) {
if (t_ch == '\0')
break;
- if ((matched = dowild(p, text)) != NOMATCH) {
+ if ((matched = dowild(p, text, force_lower_case)) != NOMATCH) {
if (!special || matched != ABORT_TO_STARSTAR)
return matched;
} else if (!special t_ch == '/')
@@ -215,17 +213,8 @@ static int dowild(const uchar *p, const uchar *text)
}
/* Match the pattern against the text string. */
-int wildmatch(const char *pattern, const char *text)
-{
-return dowild((const uchar*)pattern, (const uchar*)text);
-}
-
-/* Match the pattern against the forced-to-lower-case text string. */
-int iwildmatch(const char *pattern, const char *text)
+int wildmatch(const char *pattern, const char *text, int flags)
{
-int ret;
-force_lower_case = 1;
-ret = dowild((const uchar*)pattern, (const uchar*)text);
-force_lower_case = 0;
-return ret;
+return dowild((const uchar*)pattern, (const uchar*)text,
+ flags FNM_CASEFOLD ? 1 : 0);
}
diff --git a/wildmatch.h b/wildmatch.h
index 562faa3..e974f9a 100644
--- a/wildmatch.h
+++ b/wildmatch.h
@@ -1,4 +1,3 @@
/* wildmatch.h */
-int wildmatch(const char *pattern, const char *text);
-int iwildmatch(const char *pattern, const char *text);
+int wildmatch(const char *pattern, const char *text, int flags);
--
1.7.12.1.406.g6ab07c4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 08/12] wildmatch: fix case-insensitive matching
dowild() does case insensitive matching by lower-casing the text. That
means lower case letters in patterns imply case-insensitive matching,
but upper case means exact matching.
We do not want that subtlety. Lower case pattern too so iwildmatch()
always does what we expect it to do.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
wildmatch.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/wildmatch.c b/wildmatch.c
index d18d721..b700631 100644
--- a/wildmatch.c
+++ b/wildmatch.c
@@ -72,6 +72,8 @@ static int dowild(const uchar *p, const uchar *text, int
force_lower_case)
return ABORT_ALL;
if (force_lower_case ISUPPER(t_ch))
t_ch = tolower(t_ch);
+ if (force_lower_case ISUPPER(p_ch))
+ p_ch = tolower(p_ch);
switch (p_ch) {
case '\\':
/* Literal match with following character. Note that the test
--
1.7.12.1.406.g6ab07c4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 09/12] wildmatch: adjust ** behavior
Standard wildmatch() sees consecutive asterisks as * that can also
match slashes. But that may be hard to explain to users as
abc/**/def can match abcdef, abcxyzdef, abc/def, abc/x/def,
abc/x/y/def...
This patch changes wildmatch so that users can do
- **/def - all paths ending with file/directory 'def'
- abc/** - equivalent to /abc/
- abc/**/def - abc/x/def, abc/x/y/def...
- otherwise consider the pattern malformed if ** is found
Basically the magic of ** only remains if it's wrapped around by
slashes.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
t/t3070-wildmatch.sh | 5 +++--
wildmatch.c | 13 +++--
wildmatch.h | 6 ++
3 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index bb92f8d..f6c64be 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -36,7 +36,7 @@ match 0 0 foobar 'foo\*bar'
match 1 1 'f\oo' 'f\\oo'
match 1 1 ball '*[al]?'
match 0 0 ten '[ten]'
-match 1 1 ten '**[!te]'
+match 0 1 ten '**[!te]'
match 0 0 ten '**[!ten]'
match 1 1 ten 't[a-g]n'
match 0 0 ten 't[!a-g]n'
@@ -51,7 +51,8 @@ match 1 1 ']' ']'
# Extended slash-matching features
match 0 0 'foo/baz/bar' 'foo*bar'
-match 1 0 'foo/baz/bar' 'foo**bar'
+match 0 0 'foo/baz/bar' 'foo**bar'
+match 0 1 'foobazbar' 'foo**bar'
match 0 0 'foo/bar' 'foo?bar'
match 0 0 'foo/bar' 'foo[/]bar'
match 0 0 'foo/bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
diff --git a/wildmatch.c b/wildmatch.c
index b700631..e09a459 100644
--- a/wildmatch.c
+++ b/wildmatch.c
@@ -21,11 +21,6 @@ typedef unsigned char uchar;
#define FALSE 0
#define TRUE 1
-#define NOMATCH 1
-#define MATCH 0
-#define ABORT_ALL -1
-#define ABORT_TO_STARSTAR -2
-
#define CC_EQ(class, len, litmatch) ((len) == sizeof (litmatch)-1 \
*(class) == *(litmatch) \
strncmp((char*)class, litmatch, len) ==
0)
@@ -91,8 +86,14 @@ static int dowild(const uchar *p, const uchar *text, int
force_lower_case)
continue;
case '*':
if (*++p == '*') {
+ const uchar *prev_p = p - 2;
while (*++p == '*') {}
- special = TRUE;
+ if ((prev_p == text || *prev_p == '/') ||
+ (*p == '\0' || *p == '/' ||
+(p[0] == '\\' p[1] == '/'))) {
+ special = TRUE;
+ } else
+ return ABORT_MALFORMED;
} else
special = FALSE;
if (*p == '\0') {
diff --git a/wildmatch.h b/wildmatch.h
index e974f9a..984a38c 100644
--- a/wildmatch.h
+++ b/wildmatch.h
@@ -1,3 +1,9 @@
/* wildmatch.h */
+#define ABORT_MALFORMED 2
+#define NOMATCH 1
+#define MATCH 0
+#define ABORT_ALL -1
+#define ABORT_TO_STARSTAR -2
+
int wildmatch(const char *pattern, const char *text, int flags);
--
1.7.12.1.406.g6ab07c4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 10/12] wildmatch: make /**/ match zero or more directories
foo/**/bar matches foo/x/bar, foo/x/y/bar... but not
foo/bar. We make a special case, when foo/**/ is detected (and
foo/ part is already matched), try matching bar with the rest of
the string.
Match one or more directories semantics can be easily achieved using
foo/*/**/bar.
This also makes **/foo match foo in addition to x/foo,
x/y/foo..
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
t/t3070-wildmatch.sh | 8 +++-
wildmatch.c | 17 +
2 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index f6c64be..f21da6c 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -53,11 +53,17 @@ match 1 1 ']' ']'
match 0 0 'foo/baz/bar' 'foo*bar'
match 0 0 'foo/baz/bar' 'foo**bar'
match 0 1 'foobazbar' 'foo**bar'
+match 1 1 'foo/baz/bar' 'foo/**/bar'
+match 1 0 'foo/baz/bar' 'foo/**/**/bar'
+match 1 0 'foo/b/a/z/bar' 'foo/**/bar'
+match 1 0 'foo/b/a/z/bar' 'foo/**/**/bar'
+match 1 0 'foo/bar' 'foo/**/bar'
+match 1 0 'foo/bar' 'foo/**/**/bar'
match 0 0 'foo/bar' 'foo?bar'
match 0 0 'foo/bar' 'foo[/]bar'
match 0 0 'foo/bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
match 1 1 'foo-bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
-match 0 0 'foo' '**/foo'
+match 1 0 'foo' '**/foo'
match 1 1 '/foo' '**/foo'
match 1 0 'bar/baz/foo' '**/foo'
match 0 0 'bar/baz/foo' '*/foo'
diff --git a/wildmatch.c b/wildmatch.c
index e09a459..f060bb0 100644
--- a/wildmatch.c
+++ b/wildmatch.c
@@ -91,6 +91,23 @@ static int dowild(const uchar *p, const uchar *text, int
force_lower_case)
if ((prev_p == text || *prev_p == '/') ||
(*p == '\0' || *p == '/' ||
(p[0] == '\\' p[1] == '/'))) {
+ /*
+* Assuming we already match 'foo/' and are at
+* star star slash, just assume it matches
+* nothing and go ahead match the rest of the
+* pattern with the remaining string. This
+* helps make foo/**/bar ( because
+* otherwise it breaks C comment syntax) match
+* both foo/bar and foo/a/bar.
+*
+* Crazy patterns like /**/**/ are
+* treated like /**/. But undefined
+* behavior is even appropriate for people
+* writing such a pattern.
+*/
+ if (p[0] == '/'
+ dowild(p + 1, text, force_lower_case) == MATCH)
+ return MATCH;
special = TRUE;
} else
return ABORT_MALFORMED;
--
1.7.12.1.406.g6ab07c4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 11/12] Support ** wildcard in .gitignore and .gitattributes
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/gitattributes.txt| 6 ++
Documentation/gitignore.txt| 19 +++
attr.c | 4 +++-
dir.c | 4 +++-
t/t0003-attributes.sh | 38 ++
t/t3001-ls-files-others-exclude.sh | 19 +++
6 files changed, 88 insertions(+), 2 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 99ed04d..93c542b 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -57,6 +57,12 @@ overrides an earlier line. This overriding is done per
attribute. The rules how the pattern matches paths are the
same as in `.gitignore` files; see linkgit:gitignore[5].
+Note that if a .gitignore rule matches a directory, the directory
+is ignored, which may be seen as ignore attribute propagated to
+to all files and directories inside. If a .gitattributes rule
+matches a directory, it manipulates attributes on that directory
+only, not files and directories inside.
+
When deciding what attributes are assigned to a path, git
consults `$GIT_DIR/info/attributes` file (which has the highest
precedence), `.gitattributes` file in the same directory as the
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index 96639e0..b564b4b 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -104,6 +104,25 @@ PATTERN FORMAT
For example, /{asterisk}.c matches cat-file.c but not
mozilla-sha1/sha1.c.
+Two consecutive asterisks (`**`) in patterns matched against
+full pathname may have special meaning:
+
+ - A leading `**` followed by a slash means match in all
+ directories. For example, `**/foo` matches file or directory
+ `foo` anywhere, the same as pattern `foo`. **/foo/bar
+ matches file or directory `bar` anywhere that is directly
+ under directory `foo`.
+
+ - A trailing /** matches everything inside. For example,
+ abc/** matches all files inside directory abc, relative
+ to the location of the `.gitignore` file, with infinite depth.
+
+ - A slash followed by two consecutive asterisks then a slash
+ matches zero or more directories. For example, `a/**/b`
+ matches `a/b`, `a/x/b`, `a/x/y/b` and so on.
+
+ - Other consecutive asterisks are considered invalid.
+
NOTES
-
diff --git a/attr.c b/attr.c
index 887a9ae..8010429 100644
--- a/attr.c
+++ b/attr.c
@@ -12,6 +12,7 @@
#include exec_cmd.h
#include attr.h
#include dir.h
+#include wildmatch.h
const char git_attr__true[] = (builtin)true;
const char git_attr__false[] = \0(builtin)false;
@@ -666,7 +667,8 @@ static int path_matches(const char *pathname, int pathlen,
return 0;
if (baselen != 0)
baselen++;
- return fnmatch_icase(pattern, pathname + baselen, FNM_PATHNAME) == 0;
+ return wildmatch(pattern, pathname + baselen,
+ignore_case ? FNM_CASEFOLD : 0) == 0;
}
static int macroexpand_one(int attr_nr, int rem);
diff --git a/dir.c b/dir.c
index 4868339..442db1c 100644
--- a/dir.c
+++ b/dir.c
@@ -8,6 +8,7 @@
#include cache.h
#include dir.h
#include refs.h
+#include wildmatch.h
struct path_simplify {
int len;
@@ -575,7 +576,8 @@ int excluded_from_list(const char *pathname,
namelen -= prefix;
}
- if (!namelen || !fnmatch_icase(exclude, name, FNM_PATHNAME))
+ if (!namelen ||
+ wildmatch(exclude, name, ignore_case ? FNM_CASEFOLD : 0) ==
0)
return to_exclude;
}
return -1; /* undecided */
diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
index febc45c..67a5694 100755
--- a/t/t0003-attributes.sh
+++ b/t/t0003-attributes.sh
@@ -232,4 +232,42 @@ test_expect_success 'bare repository: test
info/attributes' '
attr_check subdir/a/i unspecified
'
+test_expect_success '** test' '
+ cd ..
+ echo **/f foo=bar .gitattributes
+ cat \EOF expect
+f: foo: bar
+a/f: foo: bar
+a/b/f: foo: bar
+a/b/c/f: foo: bar
+EOF
+ git check-attr foo -- f actual 2err
+ git check-attr foo -- a/f actual 2err
+ git check-attr foo -- a/b/f actual 2err
+ git check-attr foo -- a/b/c/f actual 2err
+ test_cmp expect actual
+ test_line_count = 0 err
+'
+
+test_expect_success '** with no slashes test' '
+ echo a**f foo=bar .gitattributes
+ git check-attr foo -- f actual
+ cat \EOF expect
+f: foo: unspecified
+af: foo: bar
+axf: foo: bar
+a/f: foo: unspecified
+a/b/f: foo: unspecified
+a/b/c/f: foo: unspecified
+EOF
+ git check-attr foo -- f actual 2err
+ git check-attr foo -- af actual 2err
+ git check-attr foo -- axf actual 2err
+ git check-attr foo -- a/f actual 2err
+ git check-attr foo -- a/b/f actual 2err
+ git
Re: [PATCH 0/5] Cure some format-patch wrapping and encoding issues
Am 09.10.2012 21:07, schrieb Junio C Hamano: Jan H. Schönherr schn...@cs.tu-berlin.de writes: During the creation of this series, I came across the strbuf wrapping functions, and I wonder if there is an off-by-one issue. Consider the following excerpt from t4202: ... Yeah, that does sound like an off-by-one bug. When we as end users say %w(72), we do expect some lines fill to the 72nd column, not stopping at the 71st. I suspect that dates back to the very first implementation of %w() but I think we should fix it (perhaps as a separate patch either the earliest or the last in the series). I will include a fix for that, then. (But I won't be able the send out the next round of this series before next week.) Regards Jan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 'git grep needle rev' attempts to access 'rev:.../.gitattributes' in the worktree
On Wed, Oct 10, 2012 at 1:59 AM, Junio C Hamano gits...@pobox.com wrote: Jeff King p...@peff.net writes: I think we just need to have callers of grep_source_init provide us with the actual pathname (or NULL, in the case of GREP_SOURCE_BUF). That is where the information is lost. Yes. I agree that is the right approach. Here we go. No additional tests as I don't know how to write them. But strace shows it's ok. Currently we don't have many options to optimize attr access. We cannot prepare a attr stack in advance for a specific directory, then check attributes many times using the stack. We cannot prepare attr stack from a tree object. As a result a normal grep pattern -- results in a lot of duplicate failed open(.../.gitattributes) calls. Jeff King (1): grep: pass true path name to grep machinery Nguyễn Thái Ngọc Duy (2): quote: let caller reset buffer for quote_path_relative() grep: stop looking at random places for .gitattributes Documentation/git-grep.txt | 7 +-- builtin/clean.c| 2 ++ builtin/grep.c | 19 --- builtin/ls-files.c | 1 + grep.c | 11 --- grep.h | 4 +++- quote.c| 1 - wt-status.c| 1 + 8 files changed, 32 insertions(+), 14 deletions(-) -- 1.7.12.1.406.g6ab07c4 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] quote: let caller reset buffer for quote_path_relative()
quote_path_relative() resetting output buffer is sometimes unnecessary
as the buffer has never been used, and some other times makes it
harder for the caller to use (see builtin/grep.c, the caller has to
insert a string after quote_path_relative)
Move the buffer reset back to call sites when necessary.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
The answer for Jeff's XXX in his patch, why strbuf_insert() instead
of just adding in advance.
builtin/clean.c| 2 ++
builtin/grep.c | 2 +-
builtin/ls-files.c | 1 +
quote.c| 1 -
wt-status.c| 1 +
5 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/builtin/clean.c b/builtin/clean.c
index 69c1cda..ff633cc 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -149,6 +149,7 @@ int cmd_clean(int argc, const char **argv, const char
*prefix)
if (S_ISDIR(st.st_mode)) {
strbuf_addstr(directory, ent-name);
+ strbuf_reset(buf);
qname = quote_path_relative(directory.buf,
directory.len, buf, prefix);
if (show_only (remove_directories ||
(matches == MATCHED_EXACTLY))) {
@@ -171,6 +172,7 @@ int cmd_clean(int argc, const char **argv, const char
*prefix)
} else {
if (pathspec !matches)
continue;
+ strbuf_reset(buf);
qname = quote_path_relative(ent-name, -1, buf,
prefix);
if (show_only) {
printf(_(Would remove %s\n), qname);
diff --git a/builtin/grep.c b/builtin/grep.c
index 82530a6..377c904 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -376,9 +376,9 @@ static int grep_sha1(struct grep_opt *opt, const unsigned
char *sha1,
struct strbuf pathbuf = STRBUF_INIT;
if (opt-relative opt-prefix_length) {
+ strbuf_add(pathbuf, filename, tree_name_len);
quote_path_relative(filename + tree_name_len, -1, pathbuf,
opt-prefix);
- strbuf_insert(pathbuf, 0, filename, tree_name_len);
} else {
strbuf_addstr(pathbuf, filename);
}
diff --git a/builtin/ls-files.c b/builtin/ls-files.c
index b5434af..1e0cae9 100644
--- a/builtin/ls-files.c
+++ b/builtin/ls-files.c
@@ -395,6 +395,7 @@ int report_path_error(const char *ps_matched, const char
**pathspec, const char
if (found_dup)
continue;
+ strbuf_reset(sb);
name = quote_path_relative(pathspec[num], -1, sb, prefix);
error(pathspec '%s' did not match any file(s) known to git.,
name);
diff --git a/quote.c b/quote.c
index 911229f..7e23ba9 100644
--- a/quote.c
+++ b/quote.c
@@ -381,7 +381,6 @@ char *quote_path_relative(const char *in, int len,
{
struct strbuf sb = STRBUF_INIT;
const char *rel = path_relative(in, len, sb, prefix, -1);
- strbuf_reset(out);
quote_c_style_counted(rel, strlen(rel), out, NULL, 0);
strbuf_release(sb);
diff --git a/wt-status.c b/wt-status.c
index 2a9658b..be8b600 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -690,6 +690,7 @@ static void wt_status_print_other(struct wt_status *s,
struct string_list_item *it;
const char *path;
it = (l-items[i]);
+ strbuf_reset(buf);
path = quote_path(it-string, strlen(it-string),
buf, s-prefix);
if (column_active(s-colopts)) {
--
1.7.12.1.406.g6ab07c4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] grep: stop looking at random places for .gitattributes
grep searches for .gitattributes using name field in struct grep_source but that field is not real on-disk path name. For example, grep pattern rev fills the field with rev:path, which is non-existent usually until somebody exploits it to drive git away. attr does not support looking up .gitattributes from a tree object. Making git grep pattern rev support .gitattributes could be a big work. Just note in document what we support for now. The document changes in this patch are to be reverted once support is in place. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- Documentation/git-grep.txt | 7 +-- grep.c | 3 ++- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt index cfecf84..a4c66ee 100644 --- a/Documentation/git-grep.txt +++ b/Documentation/git-grep.txt @@ -86,7 +86,9 @@ OPTIONS files. -I:: - Don't match the pattern in binary files. + Don't match the pattern in binary files. Note that binary + detection via .gitattributes only works with searching files + in working directory. --max-depth depth:: For each pathspec given on command line, descend at most depth @@ -189,7 +191,8 @@ OPTIONS the match, unless the matching line is a function name itself. The name is determined in the same way as 'git diff' works out patch hunk headers (see 'Defining a custom hunk-header' in - linkgit:gitattributes[5]). + linkgit:gitattributes[5]). Note that .gitattributes are only + support for searching files in working directory. -num:: -C num:: diff --git a/grep.c b/grep.c index 06bc1c6..e36c01b 100644 --- a/grep.c +++ b/grep.c @@ -1505,7 +1505,8 @@ void grep_source_load_driver(struct grep_source *gs) return; grep_attr_lock(); - gs-driver = userdiff_find_by_path(gs-name); + if (gs-path) + gs-driver = userdiff_find_by_path(gs-path); if (!gs-driver) gs-driver = userdiff_find_by_name(default); grep_attr_unlock(); -- 1.7.12.1.406.g6ab07c4 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] grep: pass true path name to grep machinery
From: Jeff King p...@peff.net
Having path name (if available) may be useful. For example, if grep
machinery needs to look up git attributes, it'll need a good path
name. grep_source-name is not good because it's for display purpose
only.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/grep.c | 17 +++--
grep.c | 8 ++--
grep.h | 4 +++-
3 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/builtin/grep.c b/builtin/grep.c
index 377c904..0211e35 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -86,7 +86,7 @@ static pthread_cond_t cond_result;
static int skip_first_line;
static void add_work(struct grep_opt *opt, enum grep_source_type type,
-const char *name, const void *id)
+const char *name, const char *path, const void *id)
{
grep_lock();
@@ -94,7 +94,7 @@ static void add_work(struct grep_opt *opt, enum
grep_source_type type,
pthread_cond_wait(cond_write, grep_mutex);
}
- grep_source_init(todo[todo_end].source, type, name, id);
+ grep_source_init(todo[todo_end].source, type, name, path, id);
if (opt-binary != GREP_BINARY_TEXT)
grep_source_load_driver(todo[todo_end].source);
todo[todo_end].done = 0;
@@ -383,9 +383,14 @@ static int grep_sha1(struct grep_opt *opt, const unsigned
char *sha1,
strbuf_addstr(pathbuf, filename);
}
+ /* XXX We seem to get all kinds of junk via the filename field here,
+* including partial filenames, sha1:path, etc. We could parse it
+* ourselves, but that is probably insanity. We should ask the
+* caller to break it down more for us. For now, just pass NULL. */
+
#ifndef NO_PTHREADS
if (use_threads) {
- add_work(opt, GREP_SOURCE_SHA1, pathbuf.buf, sha1);
+ add_work(opt, GREP_SOURCE_SHA1, pathbuf.buf, NULL, sha1);
strbuf_release(pathbuf);
return 0;
} else
@@ -394,7 +399,7 @@ static int grep_sha1(struct grep_opt *opt, const unsigned
char *sha1,
struct grep_source gs;
int hit;
- grep_source_init(gs, GREP_SOURCE_SHA1, pathbuf.buf, sha1);
+ grep_source_init(gs, GREP_SOURCE_SHA1, pathbuf.buf, NULL,
sha1);
strbuf_release(pathbuf);
hit = grep_source(opt, gs);
@@ -414,7 +419,7 @@ static int grep_file(struct grep_opt *opt, const char
*filename)
#ifndef NO_PTHREADS
if (use_threads) {
- add_work(opt, GREP_SOURCE_FILE, buf.buf, filename);
+ add_work(opt, GREP_SOURCE_FILE, buf.buf, filename, filename);
strbuf_release(buf);
return 0;
} else
@@ -423,7 +428,7 @@ static int grep_file(struct grep_opt *opt, const char
*filename)
struct grep_source gs;
int hit;
- grep_source_init(gs, GREP_SOURCE_FILE, buf.buf, filename);
+ grep_source_init(gs, GREP_SOURCE_FILE, buf.buf, filename,
filename);
strbuf_release(buf);
hit = grep_source(opt, gs);
diff --git a/grep.c b/grep.c
index edc7776..06bc1c6 100644
--- a/grep.c
+++ b/grep.c
@@ -1373,7 +1373,7 @@ int grep_buffer(struct grep_opt *opt, char *buf, unsigned
long size)
struct grep_source gs;
int r;
- grep_source_init(gs, GREP_SOURCE_BUF, NULL, NULL);
+ grep_source_init(gs, GREP_SOURCE_BUF, NULL, NULL, NULL);
gs.buf = buf;
gs.size = size;
@@ -1384,10 +1384,12 @@ int grep_buffer(struct grep_opt *opt, char *buf,
unsigned long size)
}
void grep_source_init(struct grep_source *gs, enum grep_source_type type,
- const char *name, const void *identifier)
+ const char *name, const char *path,
+ const void *identifier)
{
gs-type = type;
gs-name = name ? xstrdup(name) : NULL;
+ gs-path = path ? xstrdup(path) : NULL;
gs-buf = NULL;
gs-size = 0;
gs-driver = NULL;
@@ -1409,6 +1411,8 @@ void grep_source_clear(struct grep_source *gs)
{
free(gs-name);
gs-name = NULL;
+ free(gs-path);
+ gs-path = NULL;
free(gs-identifier);
gs-identifier = NULL;
grep_source_clear_data(gs);
diff --git a/grep.h b/grep.h
index c256ac6..c2cf57b 100644
--- a/grep.h
+++ b/grep.h
@@ -158,11 +158,13 @@ struct grep_source {
char *buf;
unsigned long size;
+ char *path; /* for attribute lookups */
struct userdiff_driver *driver;
};
void grep_source_init(struct grep_source *gs, enum grep_source_type type,
- const char *name, const void *identifier);
+ const char *name, const char *path,
+ const void *identifier);
void grep_source_clear_data(struct grep_source *gs);
void grep_source_clear(struct grep_source
Re: [PATCH 3/3] grep: stop looking at random places for .gitattributes
Thanks for working on this issue! Am 10/10/2012 13:34, schrieb Nguyễn Thái Ngọc Duy: + linkgit:gitattributes[5]). Note that .gitattributes are only + support for searching files in working directory. Does this mean it does not work for 'git grep --cached'? That would be a real loss. -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] grep: stop looking at random places for .gitattributes
On Wed, Oct 10, 2012 at 6:51 PM, Johannes Sixt j.s...@viscovery.net wrote: Thanks for working on this issue! Am 10/10/2012 13:34, schrieb Nguyễn Thái Ngọc Duy: + linkgit:gitattributes[5]). Note that .gitattributes are only + support for searching files in working directory. Does this mean it does not work for 'git grep --cached'? That would be a real loss. I missed this case. I don't think it works correctly before as it reads worktree's .gitattributes instead of the index version. But at least we support reading .gitattributes from index. Patches coming soon. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] grep: stop looking at random places for .gitattributes
Am 10/10/2012 14:03, schrieb Nguyen Thai Ngoc Duy: On Wed, Oct 10, 2012 at 6:51 PM, Johannes Sixt j.s...@viscovery.net wrote: Thanks for working on this issue! Am 10/10/2012 13:34, schrieb Nguyễn Thái Ngọc Duy: + linkgit:gitattributes[5]). Note that .gitattributes are only + support for searching files in working directory. Does this mean it does not work for 'git grep --cached'? That would be a real loss. I missed this case. I don't think it works correctly before as it reads worktree's .gitattributes instead of the index version. But at least we support reading .gitattributes from index. Patches coming soon. Is there already an established definition which the correct .gitattributes are? IIRC, everywhere else we are looking at the .gitattributes in the worktree, regardless of whether the object at the path in question is in the worktree, the index, or in an old commit. -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] grep: stop looking at random places for .gitattributes
On Wed, Oct 10, 2012 at 7:12 PM, Johannes Sixt j.s...@viscovery.net wrote: Is there already an established definition which the correct .gitattributes are? If I ask to grep the index then to me it should read only the index. Although other people can counter that they may want different attributes than the one stored in index, which either comes from worktree or $GIT_DIR. IIRC, everywhere else we are looking at the .gitattributes in the worktree, regardless of whether the object at the path in question is in the worktree, the index, or in an old commit. git-archive has --worktree-attributes to specify where attributes come from. Sparse checkout can choose to read index version first then worktree's or the other way around. All normal operations read worktree version, if not found index version. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] grep: stop looking at random places for .gitattributes
Am 10/10/2012 14:32, schrieb Nguyen Thai Ngoc Duy: git-archive has --worktree-attributes to specify where attributes come from. Sparse checkout can choose to read index version first then worktree's or the other way around. All normal operations read worktree version, if not found index version. So, even if I run 'git diff master~2000 master~1999', it uses the attributes from the worktree, and if not found from the index? (I would not mind, BTW.) -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] grep: stop looking at random places for .gitattributes
On Wed, Oct 10, 2012 at 7:43 PM, Johannes Sixt j.s...@viscovery.net wrote: Am 10/10/2012 14:32, schrieb Nguyen Thai Ngoc Duy: git-archive has --worktree-attributes to specify where attributes come from. Sparse checkout can choose to read index version first then worktree's or the other way around. All normal operations read worktree version, if not found index version. So, even if I run 'git diff master~2000 master~1999', it uses the attributes from the worktree, and if not found from the index? (I would not mind, BTW.) Yes. Tested and verified. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] attr: a note about the order of .gitattributes lookup
This is the documentation part of 1a9d7e9 (attr.c: read .gitattributes from index as well. - 2007-08-14) 06f33c1 (Read attributes from the index that is being checked out - 2009-03-13) Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- I looked around but did not see anywhere mentioning this. If I did not miss anything, then we should take a note about this to avoid surprises. Resend, this time git@vger is CCed. Sorry for the noise. Documentation/gitattributes.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt index 99ed04d..8c52a99 100644 --- a/Documentation/gitattributes.txt +++ b/Documentation/gitattributes.txt @@ -66,6 +66,12 @@ is from the path in question, the lower its precedence). Finally global and system-wide files are considered (they have the lowest precedence). +Normally if `.gitattributes` is not found in a directory in work tree, +the same path in the index is examined. If there's a `.gitattributes` +version in the index, that version will be used. During checkout process, +the order of examination is reversed: index version is preferred over +the work tree version. + If you wish to affect only a single repository (i.e., to assign attributes to files that are particular to one user's workflow for that repository), then -- 1.7.12.1.406.g6ab07c4 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] Re: 'git grep needle rev' attempts to access 'rev:.../.gitattributes' in the worktree
Round too. .gitattributes should be respected in all cases except blob grepping. As Johannes pointed elsewhere in this thread, if git diff rev1 rev2 looks up worktree's .gitattributes (and none in rev1/rev2), there's no reason git grep should behave differently. Nguyễn Thái Ngọc Duy (2): quote: let caller reset buffer for quote_path_relative() grep: stop looking at random places for .gitattributes builtin/clean.c| 2 ++ builtin/grep.c | 24 +--- builtin/ls-files.c | 1 + grep.c | 11 --- grep.h | 4 +++- quote.c| 1 - t/t7008-grep-binary.sh | 22 ++ wt-status.c| 1 + 8 files changed, 50 insertions(+), 16 deletions(-) -- 1.7.12.1.406.g6ab07c4 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] grep: stop looking at random places for .gitattributes
grep searches for .gitattributes using name field in struct
grep_source but that field is not real on-disk path name. For example,
grep pattern rev fills the field with rev:path, which is
non-existent usually until somebody exploits it to drive git away.
This patch passes real paths down to grep_source_load_driver(). Except
grepping a blob, all other cases should have right paths down to
grep_source_load_driver(). In other words, .gitattributes are still
respected.
Initial-work-by: Jeff King p...@peff.net
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/grep.c | 22 --
grep.c | 11 ---
grep.h | 4 +++-
t/t7008-grep-binary.sh | 22 ++
4 files changed, 45 insertions(+), 14 deletions(-)
diff --git a/builtin/grep.c b/builtin/grep.c
index 377c904..f6c5ba2 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -86,7 +86,7 @@ static pthread_cond_t cond_result;
static int skip_first_line;
static void add_work(struct grep_opt *opt, enum grep_source_type type,
-const char *name, const void *id)
+const char *name, const char *path, const void *id)
{
grep_lock();
@@ -94,7 +94,7 @@ static void add_work(struct grep_opt *opt, enum
grep_source_type type,
pthread_cond_wait(cond_write, grep_mutex);
}
- grep_source_init(todo[todo_end].source, type, name, id);
+ grep_source_init(todo[todo_end].source, type, name, path, id);
if (opt-binary != GREP_BINARY_TEXT)
grep_source_load_driver(todo[todo_end].source);
todo[todo_end].done = 0;
@@ -371,7 +371,8 @@ static void *lock_and_read_sha1_file(const unsigned char
*sha1, enum object_type
}
static int grep_sha1(struct grep_opt *opt, const unsigned char *sha1,
-const char *filename, int tree_name_len)
+const char *filename, int tree_name_len,
+const char *path)
{
struct strbuf pathbuf = STRBUF_INIT;
@@ -385,7 +386,7 @@ static int grep_sha1(struct grep_opt *opt, const unsigned
char *sha1,
#ifndef NO_PTHREADS
if (use_threads) {
- add_work(opt, GREP_SOURCE_SHA1, pathbuf.buf, sha1);
+ add_work(opt, GREP_SOURCE_SHA1, pathbuf.buf, path, sha1);
strbuf_release(pathbuf);
return 0;
} else
@@ -394,7 +395,7 @@ static int grep_sha1(struct grep_opt *opt, const unsigned
char *sha1,
struct grep_source gs;
int hit;
- grep_source_init(gs, GREP_SOURCE_SHA1, pathbuf.buf, sha1);
+ grep_source_init(gs, GREP_SOURCE_SHA1, pathbuf.buf, path,
sha1);
strbuf_release(pathbuf);
hit = grep_source(opt, gs);
@@ -414,7 +415,7 @@ static int grep_file(struct grep_opt *opt, const char
*filename)
#ifndef NO_PTHREADS
if (use_threads) {
- add_work(opt, GREP_SOURCE_FILE, buf.buf, filename);
+ add_work(opt, GREP_SOURCE_FILE, buf.buf, filename, filename);
strbuf_release(buf);
return 0;
} else
@@ -423,7 +424,7 @@ static int grep_file(struct grep_opt *opt, const char
*filename)
struct grep_source gs;
int hit;
- grep_source_init(gs, GREP_SOURCE_FILE, buf.buf, filename);
+ grep_source_init(gs, GREP_SOURCE_FILE, buf.buf, filename,
filename);
strbuf_release(buf);
hit = grep_source(opt, gs);
@@ -479,7 +480,7 @@ static int grep_cache(struct grep_opt *opt, const struct
pathspec *pathspec, int
if (cached || (ce-ce_flags CE_VALID) ||
ce_skip_worktree(ce)) {
if (ce_stage(ce))
continue;
- hit |= grep_sha1(opt, ce-sha1, ce-name, 0);
+ hit |= grep_sha1(opt, ce-sha1, ce-name, 0, ce-name);
}
else
hit |= grep_file(opt, ce-name);
@@ -518,7 +519,8 @@ static int grep_tree(struct grep_opt *opt, const struct
pathspec *pathspec,
strbuf_add(base, entry.path, te_len);
if (S_ISREG(entry.mode)) {
- hit |= grep_sha1(opt, entry.sha1, base-buf, tn_len);
+ hit |= grep_sha1(opt, entry.sha1, base-buf, tn_len,
+base-buf + tn_len);
}
else if (S_ISDIR(entry.mode)) {
enum object_type type;
@@ -548,7 +550,7 @@ static int grep_object(struct grep_opt *opt, const struct
pathspec *pathspec,
struct object *obj, const char *name)
{
if (obj-type == OBJ_BLOB)
- return grep_sha1(opt, obj-sha1, name, 0);
+ return grep_sha1(opt, obj-sha1, name, 0, NULL);
if (obj-type == OBJ_COMMIT || obj-type == OBJ_TREE) {
Re: [PATCH v2 2/2] grep: stop looking at random places for .gitattributes
Am 10/10/2012 15:59, schrieb Nguyễn Thái Ngọc Duy: This patch passes real paths down to grep_source_load_driver(). Except grepping a blob, all other cases should have right paths down to ... grepping a blob or tree object... grep_source_load_driver(). In other words, .gitattributes are still respected. ... +test_expect_success 'grep --cached respects binary diff attribute (2)' ' + git add .gitattributes + rm .gitattributes + git grep --cached text t actual + test_cmp expect actual + git checkout .gitattributes + git rm --cached .gitattributes +' This should perhaps be test_when_finished git rm --cached .gitattributes. + +test_expect_success 'grep tree respects binary diff attribute' ' I was confused by the word tree here. Isn't pathspec more correct? + git commit -m new + echo Binary file HEAD:t matches expect + git grep text HEAD -- t actual + test_cmp expect actual + git reset HEAD^ +' And in yet another test, should git grep text HEAD:t /not/ respect the binary attribute? At any rate, I don't observe the warnings anymore with this series. Thanks, -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/7] Tying loose ends on grep-pcre
On 10/10/2012 09:55 AM, Junio C Hamano wrote: It took longer than expected, but here is a reroll of the previous series to bring more recent git grep enhancements to the --grep option of commands in git log family. The early part of the series (1-3) refactors the code that reads configuration items related to grep and the code that mixes the result with the command line options to prepare grep_opt, which so far lived in builtin/grep.c, and moves them to the grep.[ch] at the top-level. The middle part (4-6) reuses the code to set-up grep_opt refactored by the earlier part of the series on revs-grep_filter that is used in git log --grep=... processing. It incidentally fixes a small bug where git log -F -E --grep='ere' did not look for matches to the pattern in extended regular expression, and adds --basic-regexp and --perl-regexp command line options to git log family for completeness. The last one teaches git log family to honor the grep.* configuration variables, e.g. grep.patterntype, so that you can say git -c grep.patterntype=perl log --grep='(?:pcre)'. Maybe this has been discussed already, but it seems to me that adding a persistent setting that affects how git log --grep interprets the pattern argument could break some scripts that assume that the old interpretation is always used. Shouldn't this at least be documented as a backwards incompatibility? Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 04/12] wildmatch: remove unnecessary functions
On 10/10/2012 12:40 PM, Nguyễn Thái Ngọc Duy wrote: Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- wildmatch.c | 161 wildmatch.h | 2 - 2 files changed, 9 insertions(+), 154 deletions(-) diff --git a/wildmatch.c b/wildmatch.c index f3a1731..71dba76 100644 --- a/wildmatch.c +++ b/wildmatch.c @@ -53,33 +53,19 @@ #define ISUPPER(c) (ISASCII(c) isupper(c)) #define ISXDIGIT(c) (ISASCII(c) isxdigit(c)) -#ifdef WILD_TEST_ITERATIONS -int wildmatch_iteration_count; -#endif - static int force_lower_case = 0; /* Match pattern p against the a virtually-joined string consisting * of text and any strings in array a. */ -static int dowild(const uchar *p, const uchar *text, const uchar*const *a) +static int dowild(const uchar *p, const uchar *text) The comment still refers to array a. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/7] Tying loose ends on grep-pcre
Michael Haggerty mhag...@alum.mit.edu writes: The last one teaches git log family to honor the grep.* configuration variables, e.g. grep.patterntype, so that you can say git -c grep.patterntype=perl log --grep='(?:pcre)'. Maybe this has been discussed already, but it seems to me that adding a persistent setting that affects how git log --grep interprets the pattern argument could break some scripts that assume that the old interpretation is always used. Shouldn't this at least be documented as a backwards incompatibility? If somebody scripts around log with hardcoded query --grep=... strings, they can force a particular variant from such a command line at the same time. But as always, responsibility of doing so is on the person who writes such a script; log being a Porcelain, we value ease-of-use in interactive case more than cast-in-stone interface stability like we do for plumbing commands. And that is exactly why the series avoids changing the behaviour for the rev-list plumbing. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MALLOC_CHECK: Allow checking to be disabled from config.mak
Junio C Hamano wrote: Ramsay Jones ram...@ramsay1.demon.co.uk writes: The malloc checks can be disabled using the TEST_NO_MALLOC_CHECK variable, either from the environment or command line of an 'make test' invocation. In order to allow the malloc checks to be disabled from the 'config.mak' file, we add TEST_NO_MALLOC_CHECK to the environment using an export directive. We would want to encourage people to test with cheap but effective checks when available. I do not see malloc: using debugging hooks message anywhere when I run tests, but if you do, I'd rather see us check if we can tell glibc to stop doing so first without disabling the whole test. Your patch feels like the first step to a slipperly slope whose destination would make us say we get too many messages so let's do nothing in make test with this configuration. when taken to the extreme, and obviously we would not want to go there ;-). [sorry for the late reply, I've been away ...] Yes, but ... I really don't see that this patch would encourage anyone to skip the malloc checks, who wasn't going to anyway! I didn't notice much of an increase in the running time of the tests, so that wouldn't discourage me. This idiotic message spewage is a different issue. (the complete loss of terminal scroll-back is particularly annoying) I had intended to run the tests with malloc checks enabled before submitting patches, testing -rc* builds etc., but have them disabled for day-to-day programming. Besides, doesn't a simple instruction to export TEST_NO_MALLOC_CHECK to your environment before running make test suffice? Yes, so I can simply disable the malloc checks in my ~/.bashrc file. However, it would be disappointing to have my config tweeks in two places ... :( I guess I can live with it ... ATB, Ramsay Jones -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MALLOC_CHECK: Allow checking to be disabled from config.mak
Elia Pinto wrote: 2012/10/6 Junio C Hamano gits...@pobox.com: Ramsay Jones ram...@ramsay1.demon.co.uk writes: Elia, you brought the MALLOC_CHECK_ up. Did you hear about this issue elsewhere before, and if you did, do you know how other projects solves it? Ok. I have found. For me this is not a problem any more these days. Was fixed in glibc 2.8.90-9 2008 * Wed Jul 16 2008 Jakub Jelinek ja...@redhat.com 2.8.90-9 - update from trunk - fix unbuffered vfprintf if writing to the stream fails (#455360) - remove useless malloc: using debugging hooks message (#455355) - nscd fixes (from glibc rpm changelog) This is the bugzilla filled and closed https://bugzilla.redhat.com/show_bug.cgi?id=455355 Ramsay, what version of glibc you have and in what distro? thanks The glibc version is 2.5, if I believe the changelog, along with: ramsay$ ls -l /lib/libc.so.6 lrwxrwxrwx 1 root root 11 2007-06-24 19:44 /lib/libc.so.6 - libc-2.5.so* ramsay$ ... but the header files tell a different story: ramsay$ grep 'define __GLIBC_' /usr/include/features.h #define __GLIBC__ 2 #define __GLIBC_MINOR__ 4 ramsay$ The distro is Ubuntu (but I can't remember which version; I would have to re-boot to find out so ...). HTH ATB, Ramsay Jones -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] attr: a note about the order of .gitattributes lookup
Nguyen Thai Ngoc Duy pclo...@gmail.com writes: This is the documentation part of 1a9d7e9 (attr.c: read .gitattributes from index as well. - 2007-08-14) 06f33c1 (Read attributes from the index that is being checked out - 2009-03-13) Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- I looked around but did not see anywhere mentioning this. If I did not miss anything, then we should take a note about this to avoid surprises. Resend, this time git@vger is CCed. Sorry for the noise. Documentation/gitattributes.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt index 99ed04d..8c52a99 100644 --- a/Documentation/gitattributes.txt +++ b/Documentation/gitattributes.txt @@ -66,6 +66,12 @@ is from the path in question, the lower its precedence). Finally global and system-wide files are considered (they have the lowest precedence). +Normally if `.gitattributes` is not found in a directory in work tree, +the same path in the index is examined. If there's a `.gitattributes` +version in the index, that version will be used. During checkout process, +the order of examination is reversed: index version is preferred over +the work tree version. + Yeah, thanks for writing it up. The direction fix was done to help people when they check out a commit when a different commit with different .gitattributes is checked out to the working tree. If you wish to affect only a single repository (i.e., to assign attributes to files that are particular to one user's workflow for that repository), then -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MALLOC_CHECK: Allow checking to be disabled from config.mak
Hemm, too old release distro , no ? 4-5 year ago. It is time to upgrade to something more recent , 5.7 5.8 . Rhel5.3 is not a good distro for a developer isn't it ? 2012/10/10, Ramsay Jones ram...@ramsay1.demon.co.uk: Junio C Hamano wrote: Ramsay Jones ram...@ramsay1.demon.co.uk writes: The malloc checks can be disabled using the TEST_NO_MALLOC_CHECK variable, either from the environment or command line of an 'make test' invocation. In order to allow the malloc checks to be disabled from the 'config.mak' file, we add TEST_NO_MALLOC_CHECK to the environment using an export directive. We would want to encourage people to test with cheap but effective checks when available. I do not see malloc: using debugging hooks message anywhere when I run tests, but if you do, I'd rather see us check if we can tell glibc to stop doing so first without disabling the whole test. Your patch feels like the first step to a slipperly slope whose destination would make us say we get too many messages so let's do nothing in make test with this configuration. when taken to the extreme, and obviously we would not want to go there ;-). [sorry for the late reply, I've been away ...] Yes, but ... I really don't see that this patch would encourage anyone to skip the malloc checks, who wasn't going to anyway! I didn't notice much of an increase in the running time of the tests, so that wouldn't discourage me. This idiotic message spewage is a different issue. (the complete loss of terminal scroll-back is particularly annoying) I had intended to run the tests with malloc checks enabled before submitting patches, testing -rc* builds etc., but have them disabled for day-to-day programming. Besides, doesn't a simple instruction to export TEST_NO_MALLOC_CHECK to your environment before running make test suffice? Yes, so I can simply disable the malloc checks in my ~/.bashrc file. However, it would be disappointing to have my config tweeks in two places ... :( I guess I can live with it ... ATB, Ramsay Jones -- Inviato dal mio dispositivo mobile -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MALLOC_CHECK: Allow checking to be disabled from config.mak
No reboot. lsb-release -a from memory or something similar, always on travel... Regards 2012/10/10, Elia Pinto gitter.spi...@gmail.com: Hemm, too old release distro , no ? 4-5 year ago. It is time to upgrade to something more recent , 5.7 5.8 . Rhel5.3 is not a good distro for a developer isn't it ? 2012/10/10, Ramsay Jones ram...@ramsay1.demon.co.uk: Junio C Hamano wrote: Ramsay Jones ram...@ramsay1.demon.co.uk writes: The malloc checks can be disabled using the TEST_NO_MALLOC_CHECK variable, either from the environment or command line of an 'make test' invocation. In order to allow the malloc checks to be disabled from the 'config.mak' file, we add TEST_NO_MALLOC_CHECK to the environment using an export directive. We would want to encourage people to test with cheap but effective checks when available. I do not see malloc: using debugging hooks message anywhere when I run tests, but if you do, I'd rather see us check if we can tell glibc to stop doing so first without disabling the whole test. Your patch feels like the first step to a slipperly slope whose destination would make us say we get too many messages so let's do nothing in make test with this configuration. when taken to the extreme, and obviously we would not want to go there ;-). [sorry for the late reply, I've been away ...] Yes, but ... I really don't see that this patch would encourage anyone to skip the malloc checks, who wasn't going to anyway! I didn't notice much of an increase in the running time of the tests, so that wouldn't discourage me. This idiotic message spewage is a different issue. (the complete loss of terminal scroll-back is particularly annoying) I had intended to run the tests with malloc checks enabled before submitting patches, testing -rc* builds etc., but have them disabled for day-to-day programming. Besides, doesn't a simple instruction to export TEST_NO_MALLOC_CHECK to your environment before running make test suffice? Yes, so I can simply disable the malloc checks in my ~/.bashrc file. However, it would be disappointing to have my config tweeks in two places ... :( I guess I can live with it ... ATB, Ramsay Jones -- Inviato dal mio dispositivo mobile -- Inviato dal mio dispositivo mobile -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
rm and add, but not rename, of identical files
I use etckeeper on some of my systems, backed by Git. On a system still using a SYSV style init I recently modified my iptables settings, changing which runlevels would stop/start the firewall. [root@drew-northup ~]# etckeeper vcs status # On branch master # Changes not staged for commit: # (use git add/rm file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: inittab # deleted:rc.d/rc2.d/K92iptables # deleted:rc.d/rc3.d/K92iptables # deleted:rc.d/rc4.d/K92iptables # deleted:rc.d/rc5.d/K92ip6tables # modified: sysconfig/ip6tables # # Untracked files: # (use git add file... to include in what will be committed) # # rc.d/rc2.d/S08iptables # rc.d/rc3.d/S08iptables # rc.d/rc4.d/S08iptables # rc.d/rc5.d/S08ip6tables no changes added to commit (use git add and/or git commit -a) It detects the changes as renames however—which in this case isn't appropriate: [root@drew-northup ~]# etckeeper vcs status # On branch master # Changes to be committed: # (use git reset HEAD file... to unstage) # # renamed:rc.d/rc2.d/K92iptables - rc.d/rc2.d/S08iptables # renamed:rc.d/rc3.d/K92iptables - rc.d/rc3.d/S08iptables # renamed:rc.d/rc4.d/K92iptables - rc.d/rc4.d/S08iptables # renamed:rc.d/rc5.d/K92ip6tables - rc.d/rc5.d/S08ip6tables # # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: inittab # modified: sysconfig/ip6tables # Is there something I should be doing to suppress rename detection in this case? (I presume changing the default—detecting as a rename—isn't such a bright idea.) [root@drew-northup ~]# etckeeper vcs --version git version 1.7.11.3 -- -Drew Northup As opposed to vegetable or mineral error? -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is anyone working on a next-gen Git protocol?
On Oct 8, 2012, at 6:27 PM, Junio C Hamano wrote: Once we go into want/have phase, I do not think there is a need for fundamental change in the protocol (by this, I am not counting a change to send haves sparsely and possibly backtracking to bisect history, etc. as fundamental). I've recently discovered that the current protocol can be amazingly inefficient when it comes to transferring binary objects. Assuming two repositories that are in sync. After a 'git checkout --orphan git commit', a subsequent transfers sends all the blobs attached to the new commit, although the other side already has all the blobs. This behavior is especially annoying when (mis)using git to store binary files. I was thinking for a while that it might be a reasonable idea to store binary files in a submodule and frequently cut the history in order to save space. The history would have little value anyway, since diff and merge don't make much sense with binary files. Eventually, I abandoned the idea due to the current behavior of the protocol. I had expected that git would be smarter and behave more like rsync, for example, by skipping big blobs as soon as it recognizes that they are already available at both sides. Maybe the new protocol could include an optimization for the described case. I don't know whether this would be a fundamental change. Steffen -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MALLOC_CHECK: Allow checking to be disabled from config.mak
Ramsay Jones ram...@ramsay1.demon.co.uk writes: Yes, so I can simply disable the malloc checks in my ~/.bashrc file. However, it would be disappointing to have my config tweeks in two places ... :( I guess I can live with it ... You could write export that-variable in your config.mak yourself ;-) Let's apply the patch as-is. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] Allow __git_ps1 to be used in PROMPT_COMMAND
Changes __git_ps1 to allow its use as PROMPT_COMMAND in bash
in addition to setting PS1 with __git_ps1 in a command substitution.
PROMPT_COMMAND has advantages for using color without running
into prompt-wrapping issues. Only by assigning \[ and \] to PS1
directly can bash know that these and the enclosed zero-width codes in
between don't count in the length of the prompt.
Signed-off-by: Simon Oosthoek s.oosth...@xs4all.nl
---
contrib/completion/git-prompt.sh | 51 +-
1 file changed, 45 insertions(+), 6 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 29b1ec9..4fbc1e6 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -10,9 +10,14 @@
#1) Copy this file to somewhere (e.g. ~/.git-prompt.sh).
#2) Add the following line to your .bashrc/.zshrc:
#source ~/.git-prompt.sh
-#3) Change your PS1 to also show the current branch:
-# Bash: PS1='[\u@\h \W$(__git_ps1 (%s))]\$ '
-# ZSH: PS1='[%n@%m %c$(__git_ps1 (%s))]\$ '
+#3a) In ~/.bashrc set PROMPT_COMMAND=__git_ps1
+#To customize the prompt, provide start/end arguments
+#PROMPT_COMMAND='__git_ps1 \u@\h:\w \\\$ '
+#3b) Alternatively change your PS1 to call __git_ps1 as
+#command-substitution:
+#Bash: PS1='[\u@\h \W$(__git_ps1 (%s))]\$ '
+#ZSH: PS1='[%n@%m %c$(__git_ps1 (%s))]\$ '
+#the optional argument will be used as format string
#
# The argument to __git_ps1 will be displayed only if you are currently
# in a git repository. The %s token will be the name of the current
@@ -194,11 +199,39 @@ __git_ps1_show_upstream ()
# __git_ps1 accepts 0 or 1 arguments (i.e., format string)
-# returns text to add to bash PS1 prompt (includes branch name)
+# when called from PS1 using command substitution
+# in this mode it prints text to add to bash PS1 prompt (includes branch name)
+#
+# __git_ps1 requires 2 arguments when called from PROMPT_COMMAND (pc)
+# in that case it _sets_ PS1. The arguments are parts of a PS1 string.
+# when both arguments are given, the first is prepended and the second appended
+# to the state string when assigned to PS1.
__git_ps1 ()
{
+ local pcmode=no
+ #defaults/examples:
+ local ps1pc_start='\u@\h:\w '
+ local ps1pc_end='\$ '
+ local printf_format='(%s)'
+
+ case $# in
+ 2) pcmode=yes
+ ps1pc_start=$1
+ ps1pc_end=$2
+ ;;
+ 0|1)printf_format=${1:-$printf_format}
+ ;;
+ *) return
+ ;;
+ esac
+
local g=$(__gitdir)
- if [ -n $g ]; then
+ if [ -z $g ]; then
+ if [ $pcmode = yes ]; then
+ #In PC mode PS1 always needs to be set
+ PS1=$ps1pc_start$ps1pc_end
+ fi
+ else
local r=
local b=
if [ -f $g/rebase-merge/interactive ]; then
@@ -284,6 +317,12 @@ __git_ps1 ()
fi
local f=$w$i$s$u
- printf -- ${1:- (%s)} $c${b##refs/heads/}${f:+ $f}$r$p
+ if [ $pcmode = yes ]; then
+ PS1=$ps1pc_start(
+ PS1=$PS1$c${b##refs/heads/}${f:+ $f}$r$p
+ PS1=$PS1)$ps1pc_end
+ else
+ printf -- $printf_format $c${b##refs/heads/}${f:+
$f}$r$p
+ fi
fi
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] Allow __git_ps1 to be used in PROMPT_COMMAND
Apologies if you receive this e-mail multiple times, my MTA was misconfigured...
Changes __git_ps1 to allow its use as PROMPT_COMMAND in bash
in addition to setting PS1 with __git_ps1 in a command substitution.
PROMPT_COMMAND has advantages for using color without running
into prompt-wrapping issues. Only by assigning \[ and \] to PS1
directly can bash know that these and the enclosed zero-width codes in
between don't count in the length of the prompt.
Signed-off-by: Simon Oosthoek s.oosth...@xs4all.nl
---
contrib/completion/git-prompt.sh | 51 +-
1 file changed, 45 insertions(+), 6 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 29b1ec9..4fbc1e6 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -10,9 +10,14 @@
#1) Copy this file to somewhere (e.g. ~/.git-prompt.sh).
#2) Add the following line to your .bashrc/.zshrc:
#source ~/.git-prompt.sh
-#3) Change your PS1 to also show the current branch:
-# Bash: PS1='[\u@\h \W$(__git_ps1 (%s))]\$ '
-# ZSH: PS1='[%n@%m %c$(__git_ps1 (%s))]\$ '
+#3a) In ~/.bashrc set PROMPT_COMMAND=__git_ps1
+#To customize the prompt, provide start/end arguments
+#PROMPT_COMMAND='__git_ps1 \u@\h:\w \\\$ '
+#3b) Alternatively change your PS1 to call __git_ps1 as
+#command-substitution:
+#Bash: PS1='[\u@\h \W$(__git_ps1 (%s))]\$ '
+#ZSH: PS1='[%n@%m %c$(__git_ps1 (%s))]\$ '
+#the optional argument will be used as format string
#
# The argument to __git_ps1 will be displayed only if you are currently
# in a git repository. The %s token will be the name of the current
@@ -194,11 +199,39 @@ __git_ps1_show_upstream ()
# __git_ps1 accepts 0 or 1 arguments (i.e., format string)
-# returns text to add to bash PS1 prompt (includes branch name)
+# when called from PS1 using command substitution
+# in this mode it prints text to add to bash PS1 prompt (includes branch name)
+#
+# __git_ps1 requires 2 arguments when called from PROMPT_COMMAND (pc)
+# in that case it _sets_ PS1. The arguments are parts of a PS1 string.
+# when both arguments are given, the first is prepended and the second appended
+# to the state string when assigned to PS1.
__git_ps1 ()
{
+ local pcmode=no
+ #defaults/examples:
+ local ps1pc_start='\u@\h:\w '
+ local ps1pc_end='\$ '
+ local printf_format='(%s)'
+
+ case $# in
+ 2) pcmode=yes
+ ps1pc_start=$1
+ ps1pc_end=$2
+ ;;
+ 0|1)printf_format=${1:-$printf_format}
+ ;;
+ *) return
+ ;;
+ esac
+
local g=$(__gitdir)
- if [ -n $g ]; then
+ if [ -z $g ]; then
+ if [ $pcmode = yes ]; then
+ #In PC mode PS1 always needs to be set
+ PS1=$ps1pc_start$ps1pc_end
+ fi
+ else
local r=
local b=
if [ -f $g/rebase-merge/interactive ]; then
@@ -284,6 +317,12 @@ __git_ps1 ()
fi
local f=$w$i$s$u
- printf -- ${1:- (%s)} $c${b##refs/heads/}${f:+ $f}$r$p
+ if [ $pcmode = yes ]; then
+ PS1=$ps1pc_start(
+ PS1=$PS1$c${b##refs/heads/}${f:+ $f}$r$p
+ PS1=$PS1)$ps1pc_end
+ else
+ printf -- $printf_format $c${b##refs/heads/}${f:+
$f}$r$p
+ fi
fi
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] show color hints based on state of the git tree
By setting GIT_PS1_SHOW_COLORHINTS when using __git_ps1
as PROMPT_COMMAND, you will get color hints in addition to
a different character (*+% etc.) to indicate the state of
the tree.
Signed-off-by: Simon Oosthoek s.oosth...@xs4all.nl
---
contrib/completion/git-prompt.sh | 36 +++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 4fbc1e6..a693565 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -53,6 +53,12 @@
# find one, or @{upstream} otherwise. Once you have set
# GIT_PS1_SHOWUPSTREAM, you can override it on a per-repository basis by
# setting the bash.showUpstream config variable.
+#
+# If you would like a colored hint about the current dirty state, set
+# GIT_PS1_SHOWCOLORHINTS to a nonempty value. When tracked files are
+# modified, the branch name turns red, when all modifications are staged
+# the branch name turns yellow and when all changes are checked in, the
+# color changes to green. The colors are currently hardcoded in the function.
# __gitdir accepts 0 or 1 arguments (i.e., location)
# returns location of .git repo
@@ -206,6 +212,7 @@ __git_ps1_show_upstream ()
# in that case it _sets_ PS1. The arguments are parts of a PS1 string.
# when both arguments are given, the first is prepended and the second appended
# to the state string when assigned to PS1.
+# In this mode you can request colored hints using GIT_PS1_SHOWCOLORHINTS=true
__git_ps1 ()
{
local pcmode=no
@@ -319,9 +326,36 @@ __git_ps1 ()
local f=$w$i$s$u
if [ $pcmode = yes ]; then
PS1=$ps1pc_start(
- PS1=$PS1$c${b##refs/heads/}${f:+ $f}$r$p
+ if [ -n ${GIT_PS1_SHOWCOLORHINT-} ]; then
+ local c_red='\e[31m'
+ local c_green='\e[32m'
+ local c_yellow='\e[33m'
+ local c_lblue='\e[1;34m'
+ local c_purple='\e[35m'
+ local c_cyan='\e[36m'
+ local c_clear='\e[0m'
+ local branchstring=$c${b##refs/heads/}
+ local branch_color=$c_green
+ local flags_color=$c_cyan
+
+ if [ $w = * ]; then
+ branch_color=$c_red
+ elif [ -n $i ]; then
+ branch_color=$c_yellow
+ fi
+
+ # Setting PS1 directly with \[ and \] around
colors
+ # is necessary to prevent wrapping issues!
+
PS1=$PS1\[$branch_color\]$branchstring\[$c_clear\]
+ if [ -n $f ]; then
+ PS1=$PS1
\[$flags_color\]$f\[$c_clear\]
+ fi
+ else
+ PS1=$PS1$c${b##refs/heads/}${f:+ $f}$r$p
+ fi
PS1=$PS1)$ps1pc_end
else
+ # NO color option unless in PROMPT_COMMAND mode
printf -- $printf_format $c${b##refs/heads/}${f:+
$f}$r$p
fi
fi
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] grep: stop looking at random places for .gitattributes
Johannes Sixt j.s...@viscovery.net writes: Is there already an established definition which the correct .gitattributes are? IIRC, everywhere else we are looking at the .gitattributes in the worktree, regardless of whether the object at the path in question is in the worktree, the index, or in an old commit. No, and it is deliberately kept vague while waiting for us to come up with a clear definition of what is correct. We could declare, from a purist's point of view, that the attribute should be taken from the same place as the path in question is taken from. When running git add foo.c, we grab the contents of foo.c from the working tree, so .gitignore from the working tree should be applied when dealing with foo.c. Similarly, the contents of blob foo.c that git checkout foo.c reads from the index would get attributes from .gitignore in the index (to find what its smudging semantics is) before it gets written out to the working tree. git diff A B may give the attributes from tree A to the preimage side while using the attributes from tree B to the postimage side. But the last example has some practical issues. Very often, people retroactively define attributes to correct earlier mistakes. If an older tree A forgot to declare that a path mybank.gnucash is a GnuCash ledger file, while a newer tree B (and the current checkout that is even newer) does [*1*], it is more useful to apply the newer definition from .gitattributes to both trees in practice (and in practice, you are much less likely to have a check-out of ancient tree while running git diff A B to compare two trees that are newer than the current check-out). Using the file from the working tree is the best approximation of we want to use the newer one, both from the semantics (i.e. you are likely to have fresher tree checked out) and the performance (i.e. reading from files in the working tree is far more trivial than reading from historical trees) point of view. So it is not so cut-and-dried that take the attributes from the same place is a good and correct definition [*2*]. [Footnote] *1* GnuCash writes, by default, a gzip compressed xml file, so I have in my .gitattributes file *.gnucash filter=gnucash and then in my .git/config [filter gnucash] clean = gzip -dc smudge = gzip -c This allows git diff to work reasonably well (if you do not mind reading diff between two versions of xml files, that is) and also helps delta compression when packing the repository. *2* Besides, the attributes are primarily used to define the semantics about the contents in question. If one file is of gnucash kind (i.e. has filter=gnucash attribute in the previous example) in one tree, and the path is of a different kind (e.g. filter=ooo that says this is an Ooo file), it is very likely that it does not even make sense, with or without content filtering, to compare them with git diff, so take the attributes from the same place would have to imply if the attributes do not match, say something similar to 'Binary files differ', which is just as useless as applying one attribute taken from a convenient but random place (i.e. the working tree). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] grep: stop looking at random places for .gitattributes
Johannes Sixt j.s...@viscovery.net writes: At any rate, I don't observe the warnings anymore with this series. What kind of warnings have you been getting? Earlier we had a bug in the jk/config-warn-on-inaccessible-paths series that made it warn when we tried to open a .gitattribute file and open() returned an error other than ENOENT. The bug was that we saw unnecessary errors when a directory that used to exist no longer exists in the working tree; we would instead get ENOTDIR in such a case that needs to be ignored. The problem was supposed to be fixed by 8e950da (attr: failure to open a .gitattributes file is OK with ENOTDIR, 2012-09-13); if you are still seeing the error, that error still may need to be addressed, regardless of Nguyễn's patch. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] attr: more matching optimizations from .gitignore
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
.gitattributes and .gitignore share the same pattern syntax but has
separate matching implementation. Over the years, ignore's
implementation accumulates more optimizations while attr's stays the
same.
This patch adds those optimizations to attr. Basically it tries to
avoid fnmatch as much as possible in favor of strncmp.
A few notes from this work is put in the documentation:
* !pattern syntax is not supported in .gitattributes as it's not
s/not supported/forbidden/;
A reader can take not supported as silently ignored, which is
not the case. An explicit forbidden does not have such a
misinterpretation.
It would save time from both of us if you can check what is queued
on 'pu'. I do not think I touched the code for off-by-one bugs
there, though.
clear what it means (e.g. !path attr is about unsetting attr, or
undefining it..)
* patterns applying to directories
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
How about this? Diff from the previous version:
diff --git a/Documentation/gitattributes.txt
b/Documentation/gitattributes.txt
index cc2ff1d..9a0ed19 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -23,7 +23,7 @@ Each line in `gitattributes` file is of form:
That is, a pattern followed by an attributes list,
separated by whitespaces. When the pattern matches the
path in question, the attributes listed on the line are given to
-the path. Only files can be attached attributes to.
+the path.
Each attribute can be in one of these states for a given path:
@@ -58,6 +58,13 @@ attribute. The rules how the pattern matches paths are
the
same as in `.gitignore` files; see linkgit:gitignore[5].
Unlike `.gitignore`, negative patterns are not supported.
+Note that if a .gitignore rule matches a directory, the directory
+is ignored, which may be seen as assigning ignore attribute the
+directory and all files and directories inside. However, if a
+.gitattributes rule matches a directory, it manipulates
+attributes on that directory only, not files and directories
+inside.
Why do you even need to mention .gitignore in gitattributes manual
where it is irrelevant from the reader's point of view?
Besides, the interpretation the may be seen as suggests is
actively wrong. It is assigning ignore-this-and-below attribute
to the directory, and there is no inconsistency between the two.
Again, I'd suggest dropping this addition.
diff --git a/attr.c b/attr.c
index 7e85f82..4faf1ff 100644
--- a/attr.c
+++ b/attr.c
@@ -250,7 +250,6 @@ static struct match_attr *parse_attr_line(const char
*line, const char *src,
else {
char *p = (char *)(res-state[num_attr]);
memcpy(p, name, namelen);
- p[namelen] = 0;
res-u.pat.pattern = p;
parse_exclude_pattern(res-u.pat.pattern,
res-u.pat.patternlen,
@@ -690,16 +689,18 @@ static int path_matches(const char *pathname, int
pathlen,
* contain the trailing slash
*/
- if (pathlen baselen ||
+ if (pathlen baselen + 1 ||
(baselen pathname[baselen] != '/') ||
- strncmp(pathname, base, baselen))
+ strncmp_icase(pathname, base, baselen))
return 0;
namelen = baselen ? pathlen - baselen - 1 : pathlen;
name = pathname + pathlen - namelen;
- /* if the non-wildcard part is longer than the remaining
- pathname, surely it cannot match */
+ /*
+ * if the non-wildcard part is longer than the remaining
+ * pathname, surely it cannot match
+ */
if (!namelen || prefix namelen)
return 0;
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rm and add, but not rename, of identical files
Drew Northup drew.nort...@maine.edu writes: It detects the changes as renames however—which in this case isn't appropriate: Why is that a problem? A rename is just something which is computed on the fly for display purpose, the repository only stores a snapshot of the resulting tree. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2] git svn: work around SVN 1.7 mishandling of svn:special changes
Jonathan Nieder jrnie...@gmail.com wrote:
Jonathan Nieder wrote:
Revisions prepared with ordinary svn commands (svn add and not svn
propset) don't trip this because they represent filetype changes
using a replace operation [...]
Perhaps git
svn should mimic that,
... and here's what that looks like. I like this more than ignoring
the problem in tests, and I suppose something like this is necessary
regardless of how quickly issue 4091 is fixed for compatibility with
the broken versions of svn.
I prefer this v2 more than ignoring the problem in tests, too.
It would be nice if the patch could be more concise, though. What do
you think?
I think it's fine.
git-svn.perl | 25 -
I needed to filter the patch through:
s,git-svn\.perl,perl/Git/SVN/Editor.pm,g
though... Will push the edited version to my master on
git://bogomips.org/git-svn
From b8c78e2a9d6141589202e98b898f477861fcb111 Mon Sep 17 00:00:00 2001
From: Jonathan Nieder jrnie...@gmail.com
Date: Tue, 9 Oct 2012 03:12:39 -0700
Subject: [PATCH] git svn: work around SVN 1.7 mishandling of svn:special
changes
Subversion represents symlinks as ordinary files with content starting
with link and the svn:special property set to *. Thus a file can
switch between being a symlink and a non-symlink simply by toggling
its svn:special property, and new checkouts will automatically write a
file of the appropriate type. Likewise, in subversion 1.6 and older,
running svn update would notice changes in filetype and update the
working copy appropriately.
Starting in subversion 1.7 (issue 4091), changes to the svn:special
property trip an assertion instead:
$ svn up svn-tree
Updating 'svn-tree':
svn: E235000: In file 'subversion/libsvn_wc/update_editor.c' \
line 1583: assertion failed (action == svn_wc_conflict_action_edit \
|| action == svn_wc_conflict_action_delete || action == \
svn_wc_conflict_action_replace)
Revisions prepared with ordinary svn commands (svn add and not svn
propset) don't trip this because they represent these filetype
changes using a replace operation, which is approximately equivalent
to removal followed by adding a new file and works fine. Follow suit.
Noticed using t9100. After this change, git-svn's file-to-symlink
changes are sent in a format that modern svn update can handle and
tests t9100.11-13 pass again.
[ew: s,git-svn\.perl,perl/Git/SVN/Editor.pm,g]
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
Signed-off-by: Eric Wong normalper...@yhbt.net
---
perl/Git/SVN/Editor.pm | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/perl/Git/SVN/Editor.pm b/perl/Git/SVN/Editor.pm
index 755092f..3bbc20a 100644
--- a/perl/Git/SVN/Editor.pm
+++ b/perl/Git/SVN/Editor.pm
@@ -345,7 +345,30 @@ sub M {
$self-close_file($fbat,undef,$self-{pool});
}
-sub T { shift-M(@_) }
+sub T {
+ my ($self, $m, $deletions) = @_;
+
+ # Work around subversion issue 4091: toggling the is a
+ # symlink property requires removing and re-adding a
+ # file or else svn up on affected clients trips an
+ # assertion and aborts.
+ if (($m-{mode_b} =~ /^120/ $m-{mode_a} !~ /^120/) ||
+ ($m-{mode_b} !~ /^120/ $m-{mode_a} =~ /^120/)) {
+ $self-D({
+ mode_a = $m-{mode_a}, mode_b = '00',
+ sha1_a = $m-{sha1_a}, sha1_b = '0' x 40,
+ chg = 'D', file_b = $m-{file_b}
+ });
+ $self-A({
+ mode_a = '00', mode_b = $m-{mode_b},
+ sha1_a = '0' x 40, sha1_b = $m-{sha1_b},
+ chg = 'A', file_b = $m-{file_b}
+ });
+ return;
+ }
+
+ $self-M($m, $deletions);
+}
sub change_file_prop {
my ($self, $fbat, $pname, $pval) = @_;
--
1.8.0.rc0.42.gb8c78e2
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] svn test: escape peg revision separator using empty peg rev
Jonathan Nieder jrnie...@gmail.com wrote: Michael J Gruber wrote: Jonathan Nieder venit, vidit, dixit 09.10.2012 10:41: Signed-off-by: Jonathan Nieder jrnie...@gmail.com Tested with Subversion 1.6.18. Thanks both. Also pushed to master on git://bogomips.org/git-svn.git (commit 44bc5ac71fd99f195bf1a3bea63c11139d2d535f) Jonathan Nieder (2): git svn: work around SVN 1.7 mishandling of svn:special changes svn test: escape peg revision separator using empty peg rev -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is anyone working on a next-gen Git protocol?
Steffen Prohaska proha...@zib.de writes: I've recently discovered that the current protocol can be amazingly inefficient when it comes to transferring binary objects. Assuming two repositories that are in sync. After a 'git checkout --orphan git commit', a subsequent transfers sends all the blobs attached to the new commit, although the other side already has all the blobs. I do not think it has anything to do with binary, but what you deserve from using orphan, where you declared that the history does not have anything to do with the original. If both of your repositories had the two paralle lines of these histories as branches, the transfer would have went well with or without binary objects. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] git svn: work around SVN 1.7 mishandling of svn:special changes
Subversion represents symlinks as ordinary files with content starting
with link and the svn:special property set to *. Thus a file can
switch between being a symlink and a non-symlink simply by toggling
its svn:special property, and new checkouts will automatically write a
file of the appropriate type. Likewise, in subversion 1.6 and older,
running svn update would notice changes in filetype and update the
working copy appropriately.
Starting in subversion 1.7 (issue 4091), changes to the svn:special
property trip an assertion instead:
$ svn up svn-tree
Updating 'svn-tree':
svn: E235000: In file 'subversion/libsvn_wc/update_editor.c' \
line 1583: assertion failed (action == svn_wc_conflict_action_edit \
|| action == svn_wc_conflict_action_delete || action == \
svn_wc_conflict_action_replace)
Revisions prepared with ordinary svn commands (svn add and not svn
propset) don't trip this because they represent these filetype
changes using a replace operation, which is approximately equivalent
to removal followed by adding a new file and works fine. Follow suit.
Noticed using t9100. After this change, git-svn's file-to-symlink
changes are sent in a format that modern svn update can handle and
tests t9100.11-13 pass again.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Eric Wong wrote:
I needed to filter the patch through:
s,git-svn\.perl,perl/Git/SVN/Editor.pm,g
though...
Yeah, good catch. Here's a v3 tested against master. Unlike in v2,
it remembers to pass the $deletions parameter to D() and A() --- which
shouldn't make a difference because we are not adding a directory, but
it's nice to be consistent to make reading smoother.
perl/Git/SVN/Editor.pm | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/perl/Git/SVN/Editor.pm b/perl/Git/SVN/Editor.pm
index 755092fd..178920c8 100644
--- a/perl/Git/SVN/Editor.pm
+++ b/perl/Git/SVN/Editor.pm
@@ -345,7 +345,30 @@ sub M {
$self-close_file($fbat,undef,$self-{pool});
}
-sub T { shift-M(@_) }
+sub T {
+ my ($self, $m, $deletions) = @_;
+
+ # Work around subversion issue 4091: toggling the is a
+ # symlink property requires removing and re-adding a
+ # file or else svn up on affected clients trips an
+ # assertion and aborts.
+ if (($m-{mode_b} =~ /^120/ $m-{mode_a} !~ /^120/) ||
+ ($m-{mode_b} !~ /^120/ $m-{mode_a} =~ /^120/)) {
+ $self-D({
+ mode_a = $m-{mode_a}, mode_b = '00',
+ sha1_a = $m-{sha1_a}, sha1_b = '0' x 40,
+ chg = 'D', file_b = $m-{file_b}
+ }, $deletions);
+ $self-A({
+ mode_a = '00', mode_b = $m-{mode_b},
+ sha1_a = '0' x 40, sha1_b = $m-{sha1_b},
+ chg = 'A', file_b = $m-{file_b}
+ }, $deletions);
+ return;
+ }
+
+ $self-M($m, $deletions);
+}
sub change_file_prop {
my ($self, $fbat, $pname, $pval) = @_;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] svn test: escape peg revision separator using empty peg rev
Eric Wong wrote:
Thanks both. Also pushed to master on git://bogomips.org/git-svn.git
(commit 44bc5ac71fd99f195bf1a3bea63c11139d2d535f)
Jonathan Nieder (2):
git svn: work around SVN 1.7 mishandling of svn:special changes
svn test: escape peg revision separator using empty peg rev
Thanks. Here's the $deletions nit as a patch on top.
-- 8 --
Subject: Git::SVN::Editor::T: pass $deletions to -A and -D
This shouldn't make a difference because the $deletions hash is
only used when adding a directory (see 379862ec, 2012-02-20) but
it's nice to be consistent to make reading smoother anyway. No
functional change intended.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
perl/Git/SVN/Editor.pm |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/perl/Git/SVN/Editor.pm b/perl/Git/SVN/Editor.pm
index 3bbc20a0..178920c8 100644
--- a/perl/Git/SVN/Editor.pm
+++ b/perl/Git/SVN/Editor.pm
@@ -358,12 +358,12 @@ sub T {
mode_a = $m-{mode_a}, mode_b = '00',
sha1_a = $m-{sha1_a}, sha1_b = '0' x 40,
chg = 'D', file_b = $m-{file_b}
- });
+ }, $deletions);
$self-A({
mode_a = '00', mode_b = $m-{mode_b},
sha1_a = '0' x 40, sha1_b = $m-{sha1_b},
chg = 'A', file_b = $m-{file_b}
- });
+ }, $deletions);
return;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] quote: let caller reset buffer for quote_path_relative()
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: quote_path_relative() resetting output buffer is sometimes unnecessary as the buffer has never been used, and some other times makes it harder for the caller to use (see builtin/grep.c, the caller has to insert a string after quote_path_relative) Move the buffer reset back to call sites when necessary. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- The answer for Jeff's XXX in his patch, why strbuf_insert() instead of just adding in advance. This sounds a lot stronger than let to me. All existing callers that assumed that buf to be emptied by the function now has to clear it. quote: stop resetting output buffer of quote_path_relative() may better describe what this really does. How should this interact with the logic in the called function that used to say if we ended up returning an empty string because the path is the same as the base, we should give ./ back, and what should the return value of this function be? To answer these questions, you must define the meaning of the string in the output buffer that already exists when the function is called. If the caller did this: strbuf_addstr(out, The path relative to your HOME is: ); quote_path_relative(path, pathlen, out, /home/pclouds/); then the answers are We still need to add ./ but !out-len is no longer a good test to decide and It should point at the first byte of what we added, not out-buf. But if the caller did this instead: srcdir = /src/; strbuf_addstr(dst, /dst/); quote_path_relative(path, pathlen, dst, srcdir); printf(cp '%s' '%s'\n, path, dst-buf); then it is nonsensical to add ./ when out-len is not zero when the function returns. So what does it mean to have an existing string in the output buffer when calling the function? Is it supposed to be a path to a directory, or just a general uninterpreted string (e.g. a message)? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] svn test: escape peg revision separator using empty peg rev
Jonathan Nieder jrnie...@gmail.com wrote: Eric Wong wrote: Thanks both. Also pushed to master on git://bogomips.org/git-svn.git (commit 44bc5ac71fd99f195bf1a3bea63c11139d2d535f) Jonathan Nieder (2): git svn: work around SVN 1.7 mishandling of svn:special changes svn test: escape peg revision separator using empty peg rev Thanks. Here's the $deletions nit as a patch on top. -- 8 -- Subject: Git::SVN::Editor::T: pass $deletions to -A and -D For future reference, it'd be slightly easier for me to apply if you included the From: (and Date:) headers so I don't have to yank+paste them myself : This shouldn't make a difference because the $deletions hash is only used when adding a directory (see 379862ec, 2012-02-20) but it's nice to be consistent to make reading smoother anyway. No functional change intended. Signed-off-by: Jonathan Nieder jrnie...@gmail.com Signed-off-by: Eric Wong normalper...@yhbt.net And pushed to master on git://bogomips.org/git-svn.git (commit a9608896587718549e82c5bae11740f2c0eac4c6) Jonathan Nieder (3): git svn: work around SVN 1.7 mishandling of svn:special changes svn test: escape peg revision separator using empty peg rev Git::SVN::Editor::T: pass $deletions to -A and -D -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] svn test: escape peg revision separator using empty peg rev
Eric Wong wrote: Jonathan Nieder jrnie...@gmail.com wrote: -- 8 -- Subject: Git::SVN::Editor::T: pass $deletions to -A and -D For future reference, it'd be slightly easier for me to apply if you included the From: (and Date:) headers so I don't have to yank+paste them myself : Ah, I assumed you were using git am --scissors. Will do next time. Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rm and add, but not rename, of identical files
Drew Northup drew.nort...@maine.edu writes: # Untracked files: # (use git add file... to include in what will be committed) # # rc.d/rc2.d/S08iptables # rc.d/rc3.d/S08iptables # rc.d/rc4.d/S08iptables ... no changes added to commit (use git add and/or git commit -a) It detects the changes as renames however―which in this case isn't appropriate: [root@drew-northup ~]# etckeeper vcs status # On branch master # Changes to be committed: # (use git reset HEAD file... to unstage) # # renamed:rc.d/rc2.d/K92iptables - rc.d/rc2.d/S08iptables # renamed:rc.d/rc3.d/K92iptables - rc.d/rc3.d/S08iptables # renamed:rc.d/rc4.d/K92iptables - rc.d/rc4.d/S08iptables #... Given that all of these six files have the same contents, I actually am slightly impressed how well Git matched them up ;-). But more seriously, why do you have rc.d/rc2.d/S08iptables untracked in the working tree but in the index to be committed? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] attr: more matching optimizations from .gitignore
Junio C Hamano gits...@pobox.com writes: Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: @@ -690,16 +689,18 @@ static int path_matches(const char *pathname, int pathlen, * contain the trailing slash */ - if (pathlen baselen || + if (pathlen baselen + 1 || (baselen pathname[baselen] != '/') || - strncmp(pathname, base, baselen)) + strncmp_icase(pathname, base, baselen)) Shouldn't the last comparison be strncmp_icase(pathname, base, baselen + 1) instead, if you are trying to match this part from dir.c where baselen does count the trailing slash? if (pathlen x-baselen || (x-baselen pathname[x-baselen-1] != '/') || strncmp_icase(pathname, x-base, x-baselen)) continue; In other words, relative to what was queued to 'pu', something like this instead And,... it doesn't work and breaks t0003.sh. Sigh... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] svn test: escape peg revision separator using empty peg rev
Jonathan Nieder jrnie...@gmail.com wrote: Eric Wong wrote: Jonathan Nieder jrnie...@gmail.com wrote: -- 8 -- Subject: Git::SVN::Editor::T: pass $deletions to -A and -D For future reference, it'd be slightly easier for me to apply if you included the From: (and Date:) headers so I don't have to yank+paste them myself : Ah, I assumed you were using git am --scissors. Will do next time. I missed the addition of --scissors. Will use it in the future : -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is anyone working on a next-gen Git protocol?
From: Junio C Hamano gits...@pobox.com Steffen Prohaska proha...@zib.de writes: I've recently discovered that the current protocol can be amazingly inefficient when it comes to transferring binary objects. Assuming two repositories that are in sync. After a 'git checkout --orphan git commit', a subsequent transfers sends all the blobs attached to the new commit, although the other side already has all the blobs. I do not think it has anything to do with binary, but what you deserve from using orphan, where you declared that the history does not have anything to do with the original. If both of your repositories had the two paralle lines of these histories as branches, the transfer would have went well with or without binary objects. -- Steffen, An alternative could be a shallow clone for just those branches with the binary objects, so that the git objects are still identical. Or use a replace/graft to trim the line of development. It's still a fudge, but something you could look at. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] svn test: escape peg revision separator using empty peg rev
Eric Wong normalper...@yhbt.net writes: Jonathan Nieder jrnie...@gmail.com wrote: Michael J Gruber wrote: Jonathan Nieder venit, vidit, dixit 09.10.2012 10:41: Signed-off-by: Jonathan Nieder jrnie...@gmail.com Tested with Subversion 1.6.18. Thanks both. Also pushed to master on git://bogomips.org/git-svn.git (commit 44bc5ac71fd99f195bf1a3bea63c11139d2d535f) Jonathan Nieder (2): git svn: work around SVN 1.7 mishandling of svn:special changes svn test: escape peg revision separator using empty peg rev Thanks; pulled. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Allow __git_ps1 to be used in PROMPT_COMMAND
Simon Oosthoek s.oosth...@xs4all.nl writes:
__git_ps1 ()
{
+ local pcmode=no
+ #defaults/examples:
+ local ps1pc_start='\u@\h:\w '
+ local ps1pc_end='\$ '
+ local printf_format='(%s)'
+ ...
This conversion is wrong, given that ...
@@ -284,6 +317,12 @@ __git_ps1 ()
fi
local f=$w$i$s$u
- printf -- ${1:- (%s)} $c${b##refs/heads/}${f:+ $f}$r$p
... the original has a SP in front. I've tentatively queued a
fix-up patch on the topic branch before merging it to 'pu'.
+ if [ $pcmode = yes ]; then
+ PS1=$ps1pc_start(
+ PS1=$PS1$c${b##refs/heads/}${f:+ $f}$r$p
+ PS1=$PS1)$ps1pc_end
+ else
+ printf -- $printf_format $c${b##refs/heads/}${f:+
$f}$r$p
+ fi
fi
}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 00/12] Wildmatch v4
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: Really small updates. I did not want to resend it this soon but this may fix the compile errors for Junio. Thanks; queued and pushed out on 'pu'. Comments later. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] attr: more matching optimizations from .gitignore
On Thu, Oct 11, 2012 at 4:41 AM, Junio C Hamano gits...@pobox.com wrote: Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: @@ -690,16 +689,18 @@ static int path_matches(const char *pathname, int pathlen, * contain the trailing slash */ - if (pathlen baselen || + if (pathlen baselen + 1 || (baselen pathname[baselen] != '/') || - strncmp(pathname, base, baselen)) + strncmp_icase(pathname, base, baselen)) Shouldn't the last comparison be strncmp_icase(pathname, base, baselen + 1) instead, base does not contain the trailing slash, so it can only match up to base[baselen-1], then fail at base[baselen], which is '\0'. The no trailing slash business in this function is tricky :( if you are trying to match this part from dir.c where baselen does count the trailing slash? if (pathlen x-baselen || (x-baselen pathname[x-baselen-1] != '/') || strncmp_icase(pathname, x-base, x-baselen)) continue; strncmp_icase() here just needs to compare x-baselen-1 chars (i.e. no trailing slash) as the trailing slash is explicitly checked just above strncmp_icase. But it does not hurt to compare an extra character so I leave it unchanged. But obviously it causes confusion when we try to match this function and the one in attr.c -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] grep: stop looking at random places for .gitattributes
On Wed, Oct 10, 2012 at 9:21 PM, Johannes Sixt j.s...@viscovery.net wrote:
+ git commit -m new
+ echo Binary file HEAD:t matches expect
+ git grep text HEAD -- t actual
+ test_cmp expect actual
+ git reset HEAD^
+'
And in yet another test, should
git grep text HEAD:t
/not/ respect the binary attribute?
Gray area. Is it ok to do that without documenting it (i.e. common
sense)? I have something in mind that could do that, but it also makes
git grep text HEAD^{tree} not respect attributes.
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is anyone working on a next-gen Git protocol?
On Wed, Oct 10, 2012 at 6:44 PM, Nguyen Thai Ngoc Duy pclo...@gmail.com wrote: On Thu, Oct 11, 2012 at 3:46 AM, Junio C Hamano gits...@pobox.com wrote: Steffen Prohaska proha...@zib.de writes: I've recently discovered that the current protocol can be amazingly inefficient when it comes to transferring binary objects. Assuming two repositories that are in sync. After a 'git checkout --orphan git commit', a subsequent transfers sends all the blobs attached to the new commit, although the other side already has all the blobs. I do not think it has anything to do with binary, but what you deserve from using orphan, where you declared that the history does not have anything to do with the original. If both of your repositories had the two paralle lines of these histories as branches, the transfer would have went well with or without binary objects. On the same inefficient subject, git does not try to share common objects for non-commit refs, for example tags pointing to trees. I have such a peculiar repo and if a new tag shares 90% the tree with existing tags, git-fetch to sends the whole tree of the new tag over the wire. It does not seem easy to fix though and is probably rare enough that does not justify proper support. As a work around, I generate commits that link all these tags/trees together in a predetermined order. Not nice but works ok. Aside from saving a huge amount of CPU during the Counting objects phase, the compressed bitmap work we presented in JGit solves this by working off the complete reachability graph, and not just some subset related to a cut made across the commit graph. Unfortunately we took a shortcut and didn't create bitmaps for non-commits, but this is a trivial modification to the algorithm and the storage. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] grep: stop looking at random places for .gitattributes
Nguyen Thai Ngoc Duy pclo...@gmail.com writes:
On Wed, Oct 10, 2012 at 9:21 PM, Johannes Sixt j.s...@viscovery.net wrote:
+ git commit -m new
+ echo Binary file HEAD:t matches expect
+ git grep text HEAD -- t actual
+ test_cmp expect actual
+ git reset HEAD^
+'
And in yet another test, should
git grep text HEAD:t
/not/ respect the binary attribute?
Gray area. Is it ok to do that without documenting it (i.e. common
sense)? I have something in mind that could do that, but it also makes
git grep text HEAD^{tree} not respect attributes.
Personally, I do not think HEAD:t is worth worrying about.
We could use the get_sha1_with_context() to get t out of HEAD:t,
and we could even enhance get_sha1_with_context() to also preserve
the value of what came before the colon, but that would mean that
these three
git grep text HEAD:t/t0200
git grep text $(git rev-parse HEAD:t/t0200)
git grep text $(git rev-parse HEAD:t):t0200
would behave differently; only the first one has any chance of
applying the correct set of .gitattributes. All of them would be
able to use the .gitattributes file contained in the tree object
that corresponds to t/t0200 (if we updated attr.c to read from tree
objects, that is), but the latter two would skip .gitattributes
files from the top-level and t directories, still using the final
fallback definition from $GIT_DIR/info/attributes file.
If we have to draw a line somewhere, the saner place to draw it is
to stop at
git grep text HEAD -- t/t0200
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mergetools/p4merge: Handle /dev/null
p4merge does not properly handle the case where /dev/null
is passed as a filename.
Workaround it by creating a temporary file for this purpose.
Reported-by: Jeremy Morton ad...@game-point.net
Signed-off-by: David Aguilar dav...@gmail.com
---
Jeremy, can you test this?
mergetools/p4merge | 25 +
1 file changed, 25 insertions(+)
diff --git a/mergetools/p4merge b/mergetools/p4merge
index 1a45c1b..295361a 100644
--- a/mergetools/p4merge
+++ b/mergetools/p4merge
@@ -1,5 +1,30 @@
diff_cmd () {
+ # p4merge does not like /dev/null
+ rm_local=
+ rm_remote=
+ if test /dev/null = $LOCAL
+ then
+ LOCAL=./p4merge-dev-null.LOCAL.$$
+ $LOCAL
+ rm_local=true
+ fi
+ if test /dev/null = $REMOTE
+ then
+ REMOTE=./p4merge-dev-null.REMOTE.$$
+ $REMOTE
+ rm_remote=true
+ fi
+
$merge_tool_path $LOCAL $REMOTE
+
+ if test -n $rm_local
+ then
+ rm -f $LOCAL
+ fi
+ if test -n $rm_remote
+ then
+ rm -f $REMOTE
+ fi
}
merge_cmd () {
--
1.8.0.rc1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Rebase doesn't restore branch pointer back on out of memory
For the 'format-patch' part, originally I was going to do something like:
git format-patch ... || {
...
}
But later I thought it's better to use a consistent style as the following
'am' part.
For the 'am' part, if we kept the following line at the end of the if-block:
fi move_to_original_branch
then, before exiting the if-block, we would have to do something like:
test 0 != $ret false
which seems a bit ugly to me. So I removed the use of '', and rearrange the
'write_basic_state' and 'move_to_original_branch' to make the logic flow a bit
better and easier to read.
Andrew Wong (1):
rebase: Handle cases where format-patch fails
git-rebase--am.sh | 51 +--
1 file changed, 45 insertions(+), 6 deletions(-)
--
1.8.0.rc0.19.gc58a63a.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] rebase: Handle cases where format-patch fails
'format-patch' could fail due to reasons such as out of memory. Such failures are not detected or handled, which causes rebase to incorrectly think that it completed successfully and continue with cleanup. i.e. calling move_to_original_branch Instead of using a pipe, we separate 'format-patch' and 'am' by using an intermediate file. This gurantees that we can invoke 'am' with the complete input, or not invoking 'am' at all if 'format-patch' failed. Also remove the use of '' at the end of the if-block, and rearrange the 'write_basic_state' and 'move_to_original_branch' to make the logic flow a bit better and easier to read. Signed-off-by: Andrew Wong andrew.k...@gmail.com --- git-rebase--am.sh | 51 +-- 1 file changed, 45 insertions(+), 6 deletions(-) diff --git a/git-rebase--am.sh b/git-rebase--am.sh index 392ebc9..85b594e 100644 --- a/git-rebase--am.sh +++ b/git-rebase--am.sh @@ -18,6 +18,7 @@ esac test -n $rebase_root root_flag=--root +ret=0 if test -n $keep_empty then # we have to do this the hard way. git format-patch completely squashes @@ -25,13 +26,51 @@ then # itself well to recording empty patches. fortunately, cherry-pick # makes this easy git cherry-pick --allow-empty $revisions + ret=$? else + rm -f $GIT_DIR/format-patch + git format-patch -k --stdout --full-index --ignore-if-in-upstream \ --src-prefix=a/ --dst-prefix=b/ \ - --no-renames $root_flag $revisions | - git am $git_am_opt --rebasing --resolvemsg=$resolvemsg -fi move_to_original_branch + --no-renames $root_flag $revisions $GIT_DIR/format-patch + ret=$? + + if test 0 != $ret + then + rm -f $GIT_DIR/format-patch + + case $head_name in + refs/heads/*) + git checkout -q $head_name + ;; + *) + git checkout -q $orig_head + ;; + esac + + cat 2 -EOF + + git encountered an error while preparing the patches to replay + these revisions: + + $revisions + + As a result, git cannot rebase these revisions. + EOF + + exit $? + fi + + git am $git_am_opt --rebasing --resolvemsg=$resolvemsg $GIT_DIR/format-patch + ret=$? + + rm -f $GIT_DIR/format-patch +fi + +if test 0 != $ret +then + test -d $state_dir write_basic_state + exit $ret +fi -ret=$? -test 0 != $ret -a -d $state_dir write_basic_state -exit $ret +move_to_original_branch -- 1.8.0.rc0.19.gc58a63a.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 00/12] Wildmatch v4
Junio C Hamano gits...@pobox.com writes: Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: Really small updates. I did not want to resend it this soon but this may fix the compile errors for Junio. t3070 seems to break TAP, *** prove *** t3070-wildmatch.sh .. Failed 1/151 subtests Test Summary Report --- t3070-wildmatch.sh (Wstat: 0 Tests: 150 Failed: 0) Parse errors: Tests out of sequence. Found (76) but expected (75) Tests out of sequence. Found (77) but expected (76) Tests out of sequence. Found (78) but expected (77) Tests out of sequence. Found (79) but expected (78) Tests out of sequence. Found (80) but expected (79) Displayed the first 5 of 77 TAP syntax errors. This probably is due to this part of the output: ok 72 - wildmatch 1 1 [ab] [\[:]ab] ok 73 - wildmatch 1 1 ?a?b \??\?b ok 74 - wildmatch 1 1 abc ^G^Hok 75 - wildmatch 0 0 foo ok 76 - wildmatch 1 0 foo/bar/baz/to **/t[o] ok 77 - wildmatch 1 1 a1B [[:alpha:]][[:digit:]][[:upper:]] -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] grep: stop looking at random places for .gitattributes
Am 10/10/2012 21:56, schrieb Junio C Hamano: Johannes Sixt j.s...@viscovery.net writes: At any rate, I don't observe the warnings anymore with this series. What kind of warnings have you been getting? Earlier we had a bug in the jk/config-warn-on-inaccessible-paths series that made it warn when we tried to open a .gitattribute file and open() returned an error other than ENOENT. The bug was that we saw unnecessary errors when a directory that used to exist no longer exists in the working tree; we would instead get ENOTDIR in such a case that needs to be ignored. I saw EINVAL errors when 'git grep pattern rev' was run on Windows. The reason is that the code attempted to access rev:dir/.gitattributes in the worktree, which is an invalid path on Windows due to the colon. The lack of this warning indicates that the attempts to access these files are eliminated. -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] grep: stop looking at random places for .gitattributes
Am 10/10/2012 21:44, schrieb Junio C Hamano: Johannes Sixt j.s...@viscovery.net writes: Is there already an established definition which the correct .gitattributes are? No, and it is deliberately kept vague while waiting for us to come up with a clear definition of what is correct. ... Very often, people retroactively define attributes to correct earlier mistakes. Absolutely. I have Windows resource files that are Shift-JIS encoded checked in long ago, and I want to retoactively declare them with encoding=Shift-JIS because I prefer to see Japanese script in gitk rather than gibberish. -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git 1.8.0.rc0.18.gf84667d trouble with git commit -p file
On Sat, Oct 6, 2012 at 12:07 PM, Jeff King p...@peff.net wrote: Are you sure? Does --only mean only the changes I am about to mark or only the paths I am about to tell you about? Without partial hunk selection (i.e., commit -p), they were the same; a path you mention is a path which will be either be staged in its entirety or not. Specifying (or omitting) the path was sufficient to say what you wanted. But with -p, I can see three useful possibilities: 1. Do not include F in the commit, even if changes are staged in the index (i.e., take HEAD exactly). 2. Include F in the commit, and stage partial changes on top of what is already staged. 3. Include F in the commit, and stage partial changes on top of HEAD. In cases 2 and 3, we are still taking only the path F. But we are not taking only what is about to be staged in 2. And I can see both being useful (2 because it is more convenient not to re-approve staged changes, and 3 because there is no way to unstage changes via -p). I think I didn't consider 2. as a viable alternative because re-approving hunks is not a problem (there are typically very few hunks per file, and you'll recognise them if you've already staged them) but not being able to unstage is a big problem (as it restricts what commits I can make with --patch without changing my index). But of course we're not specifying paths. So to me it is include the changes I am about to stage via -p, as opposed to --only use the changes I am about to stage via -p. I think the current behavior is morally equivalent to how --include works with paths (which includes the paths along with the current index, rather than only committing the paths). Or am I missing something about the distinction you're making? It seems to me that the end behavior of thinking about it either way would be the same. The way I was thinking about it was to treat the index and the command line as two orthogonal parts of the commit. --include and --only control the inclusion/exclusion of the index; while the command line arguments control which (currently unstaged) things are included. This led me to the conclusion that git commit --include is equivalent to git commit, git commit --include --all is the same as git commit --all which is why I tried to change the validation logic. (You are correct that --include --only and --interactive --all still make no sense). Here's a re-roll of the patch with --only docs tweaked. Conrad 8 Clarify that --interactive/--patch add to the existing index to avoid confusion like [1]. Make explicit that --only does not work with --interactive/--patch and clean up wording around --only --amend. [1] http://thread.gmane.org/gmane.comp.version-control.git/207108 Signed-off-by: Conrad Irwin conrad.ir...@gmail.com --- Documentation/git-commit.txt | 35 +-- 1 file changed, 17 insertions(+), 18 deletions(-) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 9594ac8..680d2bf 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -41,9 +41,9 @@ The content to be added can be specified in several ways: actual commit; 5. by using the --interactive or --patch switches with the 'commit' command - to decide one by one which files or hunks should be part of the commit, - before finalizing the operation. See the ``Interactive Mode'' section of - linkgit:git-add[1] to learn how to operate these modes. + to add files or hunks to the current index before committing. See the + ``Interactive Mode'' section of linkgit:git-add[1] to learn how to + operate these modes. The `--dry-run` option can be used to obtain a summary of what is included by any of the above for the next @@ -63,10 +63,14 @@ OPTIONS -p:: --patch:: - Use the interactive patch selection interface to chose - which changes to commit. See linkgit:git-add[1] for + Use the interactive patch selection interface to add hunks + to the index before committing. See linkgit:git-add[1] for details. +--interactive:: + Use the ``Interactive mode'' of linkgit:git-add[1] to edit + the index before committing. + -C commit:: --reuse-message=commit:: Take an existing commit object, and reuse the log message @@ -215,22 +219,17 @@ FROM UPSTREAM REBASE section in linkgit:git-rebase[1].) -i:: --include:: - Before making a commit out of staged contents so far, - stage the contents of paths given on the command line - as well. This is usually not what you want unless you - are concluding a conflicted merge. + In addition to the paths specified on the command line, + include the current contents of the index in the commit. -o:: --only:: - Make a commit only from the paths specified on the - command line, disregarding any contents that have been - staged so far. This is the default mode of operation of -
