Re: Suggestions for What's cooking
From: Junio C Hamano gits...@pobox.com Sent: Friday, September 14, 2012 3:29 AM Andrew Ardill andrew.ard...@gmail.com writes: On 14 September 2012 04:06, Junio C Hamano gits...@pobox.com wrote: Andrew Ardill andrew.ard...@gmail.com writes: short-branch-description long-branch-description notes next-steps * branch-name (creation-date) number-of-commits (merge-status) [list-of-commits] (branch-usage) I do not see how it makes any sense to have the This is where the section begins with, and its name is this line in the middle of a block indented in such a way. Care to explain? I'm not quite sure what aspect you are referring to,... Just this part, as I do not have much time. Here is your reordered one I will reject: A jc/maint-blame-no-such-path git blame MAKEFILE run in a history that has Makefile but not MAKEFILE should say No such file MAKEFILE in HEAD, but got confused on a case insensitive filesystem. B* jc/maint-blame-no-such-path (2012-09-10) 1 commit - blame $path: avoid getting fooled by case insensitive filesystems I was noting that B which *is* formatted as a header line (it EVEN has a leading asterisk to make it clear that it begins something new) is in the middle, and you added a redundant A that is not even marked clearly as a header line. Are we all working with Black text on a White background? (or is it vice versa) as this changes which bits of emphasis the eye will pick up. I'm reading the emails as black text against a white background. I find that for black text, in a block format, that one does not notice any special inital character, such as the '*', when it is part of a rectangular block. In fact I feel I tend to, if anything, down grade text begining with special characters as being bullet points below some main block text. Hence my suggestion to have either a visual break (extra line above), or a block indent (extra left hand space). Changing the contrast to white text on a black background totally changes what the eye/brain will see/notice [$dayjob is electro-optic vision systems where contrast inversion is a standard requirement for that reason]. It maybe that we are seeing different personal effects because of our set-ups. -- 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] remote-helper: allow fetch to discover sha1 later
Devin J. Pohly djpo...@gmail.com writes: From: Devin J. Pohly djpo...@gmail.com Allow a fetch-style remote helper to issue the notification ref sha1 name to specify a ref's value during the fetch operation. Currently, a remote helper with the fetch capability cannot fetch a ref unless its sha1 was known when the list command was executed. This limitation is arbitrary, as the helper may eventually be able to determine the correct sha1 as it fetches objects. While I am not fundamentally against supporting a remote helper that is not capable of saying what the object names of the tip of its histories are before doing a lot of work, I do not think it is a good idea to allow such a helper to claim that it supports fetch capability, for at least two reasons: * Being able to list is essential for fetch based helpers, I think, far from arbitrary. When running a git fetch against such a remote, we can first issue list to see what it has and avoid asking for the refs that point at the histories we already have (or the refs that are the same as the last time we fetched from the remote). I do not offhand know if we do this kind of optimization, but if we don't, we should. * Existing versions of git that can drive remote helpers that claim to have fetch capability are not prepared to accept an unknown refs protocol message from the helper, so a helper written for your new semantics of fetch capability will not work with them. The point of capability mechanism is to prevent such a compatibility issue from breaking the system, and this patch goes against that spirit. Such a remote helper should not advertise to support fetch capability, because it does not support it. It can advertise that it supports something else and it is OK to make an updated Git that knows how to drive a remote helper that lack fetch but support that something else work with it. -- 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] cherry-pick: don't forget -s on failure
In case 'git cherry-pick -s commit' failed, the user had to use 'git
commit -s' (i.e. state the -s option again), which is easy to forget
about. Instead, write the signed-off-by line early, so plain 'git
commit' will have the same result.
Also update 'git commit -s', so that in case there is already a relevant
Signed-off-by line before the Conflicts: line, it won't add one more at
the end of the message. If there is no such line, then add it before the
the Conflicts: line.
Signed-off-by: Miklos Vajna vmik...@suse.cz
---
On Thu, Sep 13, 2012 at 02:13:46PM -0700, Junio C Hamano gits...@pobox.com
wrote:
That's decl-after-stmt.
Sorry, added -Wdeclaration-after-statement to CFLAGS now.
I would have expected that you can just do strbuf_splice() to add
the sob into msgbuf with the original code structure, without a
substantial rewrite of the function like this. Perhaps I am missing
something?
I forgot about strbuf_splice(). ;-) Here is a version with it -- it's
indeed shorter, even if ends_rfc2822_footer() now has to be aware of a
possible footer.
builtin/commit.c| 79 +++---
sequencer.c | 65
sequencer.h |4 ++
t/t3507-cherry-pick-conflict.sh | 32
t/t3510-cherry-pick-sequence.sh |6 +-
t/test-lib-functions.sh | 20 +++--
6 files changed, 142 insertions(+), 64 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 778cf16..4d50484 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -28,6 +28,7 @@
#include submodule.h
#include gpg-interface.h
#include column.h
+#include sequencer.h
static const char * const builtin_commit_usage[] = {
N_(git commit [options] [--] filepattern...),
@@ -466,8 +467,6 @@ static int is_a_merge(const struct commit *current_head)
return !!(current_head-parents current_head-parents-next);
}
-static const char sign_off_header[] = Signed-off-by: ;
-
static void export_one(const char *var, const char *s, const char *e, int hack)
{
struct strbuf buf = STRBUF_INIT;
@@ -552,47 +551,6 @@ static void determine_author_info(struct strbuf
*author_ident)
}
}
-static int ends_rfc2822_footer(struct strbuf *sb)
-{
- int ch;
- int hit = 0;
- int i, j, k;
- int len = sb-len;
- int first = 1;
- const char *buf = sb-buf;
-
- for (i = len - 1; i 0; i--) {
- if (hit buf[i] == '\n')
- break;
- hit = (buf[i] == '\n');
- }
-
- while (i len - 1 buf[i] == '\n')
- i++;
-
- for (; i len; i = k) {
- for (k = i; k len buf[k] != '\n'; k++)
- ; /* do nothing */
- k++;
-
- if ((buf[k] == ' ' || buf[k] == '\t') !first)
- continue;
-
- first = 0;
-
- for (j = 0; i + j len; j++) {
- ch = buf[i + j];
- if (ch == ':')
- break;
- if (isalnum(ch) ||
- (ch == '-'))
- continue;
- return 0;
- }
- }
- return 1;
-}
-
static char *cut_ident_timestamp_part(char *string)
{
char *ket = strrchr(string, '');
@@ -717,21 +675,30 @@ static int prepare_to_commit(const char *index_file,
const char *prefix,
stripspace(sb, 0);
if (signoff) {
- struct strbuf sob = STRBUF_INIT;
- int i;
+ /*
+* See if we have a Conflicts: block at the end. If yes, count
+* its size, so we can ignore it.
+*/
+ int ignore_footer = 0;
+ int i, eol, previous = 0;
+ const char *nl;
- strbuf_addstr(sob, sign_off_header);
- strbuf_addstr(sob, fmt_name(getenv(GIT_COMMITTER_NAME),
-getenv(GIT_COMMITTER_EMAIL)));
- strbuf_addch(sob, '\n');
- for (i = sb.len - 1; i 0 sb.buf[i - 1] != '\n'; i--)
- ; /* do nothing */
- if (prefixcmp(sb.buf + i, sob.buf)) {
- if (!i || !ends_rfc2822_footer(sb))
- strbuf_addch(sb, '\n');
- strbuf_addbuf(sb, sob);
+ for (i = 0; i sb.len; i++) {
+ nl = memchr(sb.buf + i, '\n', sb.len - i);
+ if (nl)
+ eol = nl - sb.buf;
+ else
+ eol = sb.len;
+ if (!prefixcmp(sb.buf + previous, \nConflicts:\n)) {
+ ignore_footer = sb.len - previous;
+ break;
+ }
+
Re: [PATCH] rev-list/log: document logic with several limiting options
Michael J Gruber venit, vidit, dixit 14.09.2012 09:46: [snipped, just adding] ...and maybe the meaning of (or ...) and *or* isn't what I think it is either? -- 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: [PATCHv2 3/6] t7810-grep: test multiple --author with --all-match
Junio C Hamano venit, vidit, dixit 14.09.2012 01:26:
Junio C Hamano gits...@pobox.com writes:
One possible improvement we can make is to parse the command line in
the last example with --all-match to
[all-match]
(or
pattern_bodybodycommit
(or
pattern_bodybodytag
(or
pattern_headhead 1Linus
(or
pattern_headhead 0Junio
true
)
)
)
)
so that the backbone becomes
- Mentions commit,
- Mentions tag,
- Committed by Linus,
- Authored by Junio
to require that both commit and tag are mentioned in the message.
And this is an attempt to do exactly that. Earlier, when we have
both header expression (which by the way has to be an OR node by
construction) and pattern expression (which could be anything), we
created a top-level OR node (again, look at this as if you are
reading LISP),
OR
/\
/ \
patternOR
/ \ / \
.committerOR
/ \
author TRUE
in other words, the three elements on the top-level backbone are
pattern, committer and author; when there are more than one
elements in the pattern, the top-level node of it is OR, so that
node is inspected by all-match, hence the result ends up ignoring
the --all-match given from the command line.
This patch turns it into
OR
/ \
/ \
/ OR
committer/\
author\
pattern
when --all-match was given from the command line, so that the
committer, author and elements on the top-level backbone in
pattern form the top-level backbone of the resulting expression to
be inspected by the all-match logic.
Does this pass the expect-failure test in your [PATCH 5/6]?
Just a quick heads up:
I merged 38ed8ef (log --grep/--author: honor --all-match honored for
multiple --grep patterns, 2012-09-13) from pu into my test branch,
and this fixes what I had marked as known failure there. Thanks!
[I still have to figure out the logic, but begin to understand that
(OR...) and (AND...) are linewise, and all-match is a bufferwise AND
or something. Now, what is *or* ...]
grep.c | 19 +++
1 file changed, 19 insertions(+)
diff --git c/grep.c w/grep.c
index be15c47..925aa92 100644
--- c/grep.c
+++ w/grep.c
@@ -476,6 +476,22 @@ static struct grep_expr *prep_header_patterns(struct
grep_opt *opt)
return header_expr;
}
+static struct grep_expr *grep_splice_or(struct grep_expr *x, struct
grep_expr *y)
+{
+ struct grep_expr *z = x;
+
+ while (x) {
+ assert(x-node == GREP_NODE_OR);
+ if (x-u.binary.right
+ x-u.binary.right-node == GREP_NODE_TRUE) {
+ x-u.binary.right = y;
+ break;
+ }
+ x = x-u.binary.right;
+ }
+ return z;
+}
+
static void compile_grep_patterns_real(struct grep_opt *opt)
{
struct grep_pat *p;
@@ -510,6 +526,9 @@ static void compile_grep_patterns_real(struct grep_opt
*opt)
if (!opt-pattern_expression)
opt-pattern_expression = header_expr;
+ else if (opt-all_match)
+ opt-pattern_expression = grep_splice_or(header_expr,
+
opt-pattern_expression);
else
opt-pattern_expression = grep_or_expr(opt-pattern_expression,
header_expr);
--
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
[PATCHv3 02/11] log: name --debug-grep option like in the commit message
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
revision.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/revision.c b/revision.c
index 90376e8..fad8040 100644
--- a/revision.c
+++ b/revision.c
@@ -1578,7 +1578,7 @@ static int handle_revision_opt(struct rev_info *revs, int
argc, const char **arg
} else if ((argcount = parse_long_opt(grep, argv, optarg))) {
add_message_grep(revs, optarg);
return argcount;
- } else if (!strcmp(arg, --grep-debug)) {
+ } else if (!strcmp(arg, --debug-grep)) {
revs-grep_filter.debug = 1;
} else if (!strcmp(arg, --extended-regexp) || !strcmp(arg, -E)) {
revs-grep_filter.regflags |= REG_EXTENDED;
--
1.7.12.592.g41e7905
--
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
[PATCHv3 04/11] log --grep/--author: honor --all-match honored for multiple --grep patterns
From: Junio C Hamano gits...@pobox.com
Earlier, when we have both header expression (which has to be an OR
node by construction) and a pattern expression (which could be
anything), we created a top-level OR node that looks like this to
bind them together:
OR
/ \
/\
patternOR
/ \ / \
.committerOR
/ \
author TRUE
In other words, the three elements on the top-level backbone that
were inspected by the all-match logic are pattern, committer
and author. When there are more than one elements in the
pattern, the top-level node of it is that OR, so that node is
inspected by all-match, hence the result ends up ignoring the
--all-match given from the command line. A match on either side
of the pattern was considered a match, hence
git log --grep=A --grep=B --author=C --all-match
showed the same authored by C and has either A or B with or
without --all-match.
This patch turns the grep expression into this form:
OR
/ \
/ \
/ OR
committer/\
author\
pattern
when --all-match was given from the command line. This way, the
set of nodes on the top-level backbone in the resulting expression
consists of committer, author, and whatever nodes were on the
top-level backbone of the pattern expression. The all-match
logic inspects the same nodes in pattern as the case without the
author and/or the committer restriction.
Signed-off-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
grep.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/grep.c b/grep.c
index be15c47..925aa92 100644
--- a/grep.c
+++ b/grep.c
@@ -476,6 +476,22 @@ static struct grep_expr *prep_header_patterns(struct
grep_opt *opt)
return header_expr;
}
+static struct grep_expr *grep_splice_or(struct grep_expr *x, struct grep_expr
*y)
+{
+ struct grep_expr *z = x;
+
+ while (x) {
+ assert(x-node == GREP_NODE_OR);
+ if (x-u.binary.right
+ x-u.binary.right-node == GREP_NODE_TRUE) {
+ x-u.binary.right = y;
+ break;
+ }
+ x = x-u.binary.right;
+ }
+ return z;
+}
+
static void compile_grep_patterns_real(struct grep_opt *opt)
{
struct grep_pat *p;
@@ -510,6 +526,9 @@ static void compile_grep_patterns_real(struct grep_opt *opt)
if (!opt-pattern_expression)
opt-pattern_expression = header_expr;
+ else if (opt-all_match)
+ opt-pattern_expression = grep_splice_or(header_expr,
+
opt-pattern_expression);
else
opt-pattern_expression = grep_or_expr(opt-pattern_expression,
header_expr);
--
1.7.12.592.g41e7905
--
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
[PATCHv3 05/11] log: document use of multiple commit limiting options
From: Junio C Hamano gits...@pobox.com Generally speaking, using more options will further narrow the selection, but there are a few exceptions. Document them. Signed-off-by: Junio C Hamano gits...@pobox.com Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- Documentation/rev-list-options.txt | 21 + 1 file changed, 17 insertions(+), 4 deletions(-) diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt index 1ae3c89..57d6c90 100644 --- a/Documentation/rev-list-options.txt +++ b/Documentation/rev-list-options.txt @@ -3,7 +3,14 @@ Commit Limiting Besides specifying a range of commits that should be listed using the special notations explained in the description, additional commit -limiting may be applied. Note that they are applied before commit +limiting may be applied. + +Using more options generally further limits the output (e.g. +--since=date1 limits to commits newer than date1, and using it +with --grep=pattern further limits to commits whose log message +has a line that match pattern), unless otherwise noted. + +Note that these are applied before commit ordering and formatting options, such as '--reverse'. -- @@ -38,16 +45,22 @@ endif::git-rev-list[] --committer=pattern:: Limit the commits output to ones with author/committer - header lines that match the specified pattern (regular expression). + header lines that match the specified pattern (regular + expression). With more than one `--author=pattern`, + commits whose author match any of the given patterns are + chosen (similarly for multiple `--committer=pattern`). --grep=pattern:: Limit the commits output to ones with log message that - matches the specified pattern (regular expression). + matches the specified pattern (regular expression). With + more than one `--grep=pattern`, commits whose message + match any of the given patterns are chosen (but see + `--all-match`). --all-match:: Limit the commits output to ones that match all given --grep, - --author and --committer instead of ones that match at least one. + instead of ones that match at least one. -i:: --regexp-ignore-case:: -- 1.7.12.592.g41e7905 -- 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
[PATCHv3 06/11] fixup! log: document use of multiple commit limiting options
Here are a few typo fixes. There is a mix of single and back ticks already before this patch, i.e. ` vs. ' -- I thought we had guidelines for this but don't find them at the moment. Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- Documentation/rev-list-options.txt | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt index 57d6c90..c828408 100644 --- a/Documentation/rev-list-options.txt +++ b/Documentation/rev-list-options.txt @@ -6,12 +6,12 @@ special notations explained in the description, additional commit limiting may be applied. Using more options generally further limits the output (e.g. ---since=date1 limits to commits newer than date1, and using it -with --grep=pattern further limits to commits whose log message -has a line that match pattern), unless otherwise noted. +`--since=date1` limits to commits newer than `date1`, and using it +with `--grep=pattern` further limits to commits whose log message +has a line that matches `pattern`), unless otherwise noted. Note that these are applied before commit -ordering and formatting options, such as '--reverse'. +ordering and formatting options, such as `--reverse`. -- @@ -47,7 +47,7 @@ endif::git-rev-list[] Limit the commits output to ones with author/committer header lines that match the specified pattern (regular expression). With more than one `--author=pattern`, - commits whose author match any of the given patterns are + commits whose author matches any of the given patterns are chosen (similarly for multiple `--committer=pattern`). --grep=pattern:: @@ -55,7 +55,7 @@ endif::git-rev-list[] Limit the commits output to ones with log message that matches the specified pattern (regular expression). With more than one `--grep=pattern`, commits whose message - match any of the given patterns are chosen (but see + matches any of the given patterns are chosen (but see `--all-match`). --all-match:: -- 1.7.12.592.g41e7905 -- 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
[PATCHv3 03/11] grep: show --debug output only once
When threaded grep is in effect, the patterns are duplicated and recompiled for each thread. Avoid --debug output during the recompilation so that the output is given once instead of 1+nthreads times. Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- builtin/grep.c | 1 + 1 file changed, 1 insertion(+) diff --git a/builtin/grep.c b/builtin/grep.c index 8aea00c..a7e8df0 100644 --- a/builtin/grep.c +++ b/builtin/grep.c @@ -209,6 +209,7 @@ static void start_threads(struct grep_opt *opt) int err; struct grep_opt *o = grep_opt_dup(opt); o-output = strbuf_out; + o-debug = 0; compile_grep_patterns(o); err = pthread_create(threads[i], NULL, run, o); -- 1.7.12.592.g41e7905 -- 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
[PATCHv3 08/11] t7810-grep: test multiple --grep with and without --all-match
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
t/t7810-grep.sh | 16
1 file changed, 16 insertions(+)
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index 180e998..b841909 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -479,6 +479,22 @@ test_expect_success 'log grep (6)' '
test_cmp expect actual
'
+test_expect_success 'log with multiple --grep uses union' '
+ git log --grep=i --grep=r --format=%s actual
+ {
+ echo fourth echo third echo initial
+ } expect
+ test_cmp expect actual
+'
+
+test_expect_success 'log --all-match with multiple --grep uses intersection' '
+ git log --all-match --grep=i --grep=r --format=%s actual
+ {
+ echo third
+ } expect
+ test_cmp expect actual
+'
+
test_expect_success 'log --grep --author implicitly uses all-match' '
# grep matches initial and second but not third
# author matches only initial and third
--
1.7.12.592.g41e7905
--
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
[PATCHv3 11/11] t7810-grep: test --all-match with multiple --grep and --author options
--all-match is ignored with multiple author options on purpose but
requires all --grep to be matched on some line.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
t/t7810-grep.sh | 20
1 file changed, 20 insertions(+)
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index f6edb4d..b5c488e 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -531,6 +531,16 @@ test_expect_success 'log --grep --grep --author takes
union of greps and interse
test_cmp expect actual
'
+test_expect_success 'log ---all-match -grep --author --author still takes
union of authors and intersects with grep' '
+ # grep matches only initial and third
+ # author matches all but second
+ git log --all-match --author=Thor --author=Night --grep=i
--format=%s actual
+ {
+ echo third echo initial
+ } expect
+ test_cmp expect actual
+'
+
test_expect_success 'log --grep --author --author takes union of authors and
intersects with grep' '
# grep matches only initial and third
# author matches all but second
@@ -541,6 +551,16 @@ test_expect_success 'log --grep --author --author takes
union of authors and int
test_cmp expect actual
'
+test_expect_success 'log --all-match --grep --grep --author takes
intersection' '
+ # grep matches only third
+ # author matches only initial and third
+ git log --all-match --author=A U Thor --grep=i --grep=r --format=%s
actual
+ {
+ echo third
+ } expect
+ test_cmp expect actual
+'
+
test_expect_success 'grep with CE_VALID file' '
git update-index --assume-unchanged t/t
rm t/t
--
1.7.12.592.g41e7905
--
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
[PATCHv3 09/11] t7810-grep: test multiple --author with --all-match
--all-match is ignored for author matching on purpose.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
t/t7810-grep.sh | 8
1 file changed, 8 insertions(+)
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index b841909..be81d96 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -513,6 +513,14 @@ test_expect_success 'log with multiple --author uses
union' '
test_cmp expect actual
'
+test_expect_success 'log --all-match with multiple --author still uses union' '
+ git log --all-match --author=Thor --author=Aster --format=%s
actual
+ {
+ echo third echo second echo initial
+ } expect
+ test_cmp expect actual
+'
+
test_expect_success 'log with --grep and multiple --author uses all-match' '
git log --author=Thor --author=Night --grep=i --format=%s actual
{
--
1.7.12.592.g41e7905
--
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
[PATCHv3 07/11] t7810-grep: bring log --grep tests in common form
The log --grep tests generate the expected out in different ways.
Make them all use command blocks so that subshells are avoided and the
expected output is easier to grasp visually.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
t/t7810-grep.sh | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index 24e9b19..180e998 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -435,31 +435,41 @@ test_expect_success 'log grep setup' '
test_expect_success 'log grep (1)' '
git log --author=author --pretty=tformat:%s actual
- ( echo third ; echo initial ) expect
+ {
+ echo third echo initial
+ } expect
test_cmp expect actual
'
test_expect_success 'log grep (2)' '
git log --author= * -F --pretty=tformat:%s actual
- ( echo second ) expect
+ {
+ echo second
+ } expect
test_cmp expect actual
'
test_expect_success 'log grep (3)' '
git log --author=^A U --pretty=tformat:%s actual
- ( echo third ; echo initial ) expect
+ {
+ echo third echo initial
+ } expect
test_cmp expect actual
'
test_expect_success 'log grep (4)' '
git log --author=frotz\.com$ --pretty=tformat:%s actual
- ( echo second ) expect
+ {
+ echo second
+ } expect
test_cmp expect actual
'
test_expect_success 'log grep (5)' '
git log --author=Thor -F --pretty=tformat:%s actual
- ( echo third ; echo initial ) expect
+ {
+ echo third echo initial
+ } expect
test_cmp expect actual
'
@@ -473,7 +483,9 @@ test_expect_success 'log --grep --author implicitly uses
all-match' '
# grep matches initial and second but not third
# author matches only initial and third
git log --author=A U Thor --grep=s --grep=l --format=%s actual
- echo initial expect
+ {
+ echo initial
+ } expect
test_cmp expect actual
'
--
1.7.12.592.g41e7905
--
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 0/2] Mixing English and a local language
Jeff King venit, vidit, dixit 13.09.2012 20:00: On Thu, Sep 13, 2012 at 10:30:52AM -0700, Junio C Hamano wrote: But it should not be per-command, but per-message, and should include all output that is not diagnostic and is not machine-parseable (e.g., what I mentioned above, request-pull output, etc). If it is the project's language, then the team members will need to know it anyway, so it should not be too big a burden to have a potentially different language there than in the diagnostic messages. No matter what the project languages is, machine parseable part will not be localized but fixed to C anyway, so I do not think it comes into the picture. But there are parts that are neither machine-parseable nor diagnostics. The diffstat is one, but I mentioned others. Are those going to be forever fixed to LANG=C? That does not bother me, but for a project whose team works entirely in Japanese (both individually, and when sharing code), they will still be stuck with these English-language snippets, and no way to localize them. Even though they may not speak a word of it. I have no idea if such a team is a strawman or not; that is why I separated points 1 and 2. We can wait on point 2 until such a team shows up and complains (of course, they would have to come here and complain in English, so...). My take on this is, if there is the project language, it should apply to _everything_. Please do not introduce any per-command, per-message, per-anything mess. Just set LANG/LC_ALL up and be done with it. But isn't that arguing for localizing diffstat? It is not machine-parseable, so an all-Japanese team would want to localize it along with their diagnostics. -Peff The basic assumption is that we have people who are proficient in at least 2 languages. In fact, the initial i18n efforts were targeted at people who are much more comfortable in their $LANG than with LANG=C. For this category, being able to localize everything(*) is important. They will mostly work with $LANG projects. I don't think they're strawmen. For those proficient in 2 languages it's desirable to switch per project because it's likely they participate in projects with different $LANG preferences. Again, that means localizing everything(*). Additionally, setting core.i18n in global config is probably the better choice (compared to NO_GETTEXT=y) for those who are frustrated by git's translation in their usual $LANG. [git svn should pass that LANG to svn also etc.] The question is whether we have people who prefer to work with git in their $LANG even though project interaction requires a different language. They would probably run log/gitk/commit... in their $LANG but need format-patch and the like in project-lang. I do think we have people in this category here on the list, so they should speak up ;) Could they alias their format-patch to use -c core.i18n=C or such? Or have command.i18n on top? per-command config again ;) Michael -- 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: What's the point of saying HEAD is now at ...?
Junio C Hamano venit, vidit, dixit 14.09.2012 07:14:
I sometimes wonder what value the message is giving us.
For example, while reviewing a patch in my Emacs session, I may say
| git am -s3c RETURN
which runs the command on the contents of the e-mail I am reading,
to apply the patch. After that, I would go to a separate terminal
and do things like git show -U20, etc. Once I am done, I reset
the temporary commit away, and get this:
$ git reset --hard HEAD^
HEAD is now at ce5cf6f Merge git://github.com/git-l10n/git-po
or often it is
$ git reset --hard ko/master
HEAD is now at ce5cf6f Merge git://github.com/git-l10n/git-po
In either case, I know where I am resetting to, so HEAD is now at
is a less than useful noise. If it contained HEAD was at ..., it
may let me realize that I was still going to use the contents in
some other way and quickly go back to it with another reset, with
cut and paste or with HEAD@{1}. In either case, showing the tip of
what I just discarded seems to be a lot more useful information than
what we are currently giving the users.
Unless you use a git aware prompt, it's always good to know where your
HEAD is ;) Just think of:
git reset --hard HEAD^2
HEAD is now at ...
Oh, I meant HEAD~2 aka HEAD^^ ...
In that case, information about HEAD@{1} might be useful but is not
necessary, unless you are leaving behind a detached HEAD.
Cheers,
Michael
--
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 0/2] Mixing English and a local language
On Fri, Sep 14, 2012 at 5:41 PM, Michael J Gruber g...@drmicha.warpmail.net wrote: For those proficient in 2 languages it's desirable to switch per project because it's likely they participate in projects with different $LANG preferences. Again, that means localizing everything(*). Additionally, setting core.i18n in global config is probably the better choice (compared to NO_GETTEXT=y) for those who are frustrated by git's translation in their usual $LANG. [git svn should pass that LANG to svn also etc.] We should honor LINGUAS variable on installation. Only languages listed in that variable are installed. Many if not most of projects do that already. That's probably better than yet another switch. The question is whether we have people who prefer to work with git in their $LANG even though project interaction requires a different language. They would probably run log/gitk/commit... in their $LANG but need format-patch and the like in project-lang. I do think we have people in this category here on the list, so they should speak up ;) Could they alias their format-patch to use -c core.i18n=C or such? Or have command.i18n on top? per-command config again ;) Probably not needed, but probably won't hurt repeating: I do :) And things should just work, at least most of the time. When I set LANG, I prefer to have everything in $LANG unless required otherwise (sending to English speaking teams is one of them). But the exceptions should be limited. On Fri, Sep 14, 2012 at 12:52 AM, Junio C Hamano gits...@pobox.com wrote: You seem to be saying that diagnostic does not have to be in project language, but I do not think it is the right thing to do. The first response to Frotz does not work is often What do you exactly mean? How did you run Frotz? What error message are you getting from it?, and you do not want to get back the diagnostics ints Klingon. Whether you like it or not, all localized software has this problem. Perhaps the only difference with commercial software is that they have support line that also understands Klingon. I don't see any problems with asking the reporter to translate error messages back to English, assume that they report in English so they do know English. Given a specific context, Klingon illiterates can even manually revert Klingon text back to English because we have the all the translations. But it's probably faster to just ask the reporter. -- 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] Revert diffstat back to English
On Fri, Sep 14, 2012 at 7:11 AM, Jeff King p...@peff.net wrote: On Thu, Sep 13, 2012 at 02:47:09PM -0700, Junio C Hamano wrote: I agree that the line is not bright. I do not know if it is worthwhile or not. I think it will solve some practical problems, but it may also introduce others. But basically having a per-repo LANG setting (which is what the projectlang you are talking about would do) also does not seem like a solution that people will use, because they will not get any localization benefit at all. So again, I'd rather err on the side of pushing those things that are near the line into the do not translate side, letting people use LANG to localize the rest, and accepting that occasionally people are going to accidentally show you output in a language you don't understand. But hopefully that keeps it to occasionally and not every time you send out a patch. I am confused asto what you really want. In a Klingon-only project, I think it is perfectly fine to localize the diffstat summary line to Klingon. It is not machine readble, and it is not personal, but it is to be shared with project members, who all speak Klingon. Pushing more things to do not translate side of the line means robbing the benefit of i18n from people, no? Yes. But you cannot please both sides without creating a third category, as you noted. If you do not translate diffstat, then Klingon-only projects are unhappy. If you do translate, then projects run in LANG=C will either get public Klingon, or the project members will turn off all translation and lose all benefit of i18n. I agree with Jeff on this. And everything in $projectlang is just like everything in C, the problem remains. Suppose Chinese becomes a very popular language (if it has not been so), projects with dominant Chinese people would prefer Chinese. But large enough projects will involve non-Chinese people who prefer their native non-Chinese language as UI. I'm not pushing do not translate side. I just postpone it until a proper approach is found (preferably by Klingon teams who are upset about this do not translate patch). Supporting two non-C languages at the same time could be done (not very elegantly) by forking a process with the second language, which serves as gettext source for first process via pipes. The problem is drawing a line between team strings and local strings without butchering git source code. We're going through sort of the same process already, separating machine-readable strings and translatable strings. Maybe we can learn something before deciding whether to add the team string class. So for the time being, I would rather choose LANG=C as a lingua franca and err on the side of interoperability with other people and not translating. And then if and when somebody feels like putting the effort into doing i18n.projectlang by splitting out a third category, they are welcome to. I just do not see much point in doing i18n.projectlang any other way. -- 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
Using Format/export-subst Howto.
I must have missed something reading through the documentation for this. git version 1.7.11.3 $ git check-attr -a -- autorepair.d/AR02_new_rttest.sh autorepair.d/AR02_new_rttest.sh: ident: set autorepair.d/AR02_new_rttest.sh: export-subst: set echo 0..$_expected_tests diag 'Script Version: $Id: 1ca40f8395ea361cc07d2ec1a2961c3df749dc3c $' diag 'By: $Format:%cn$ $Format:%ce$' diag 'At: $Format:%cD$' I also believe that the documentation could try and better explain under what conditions $Id will be processed, it doesn't seam to happen on commit and even after a checkout this is not updated. It does seam to update during a pull and that's basically all I need. Thanks! Mike Mestnik, Michael J The ESM Tools Enterprise Systems Monitoring United States Postal Service O: (651) 406-2048 michael.j.mest...@usps.gov itenterprisesystemsmonitor...@usps.gov -- 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: inconsistent behavior on mac with case changes
On Thu, Sep 13, 2012 at 5:24 PM, Larry Martell larry.mart...@gmail.com wrote: I created a dir on my Mac called Rollup, and pushed it out. Then went to a CentOS box, pulled it, and realized I wanted to call it RollUp (capital U). I renamed it, and pushed out the change. Went back to the Mac and did a pull - it said it created the RollUp dir, but it did not - it was still called Rollup. I reamed it, but status did not pick up the change. Then I checked out a branch that had Rollup, but it was gone there - no Rollup or RollUp. I did a merge and then RollUp was created. I know the Mac is somewhat inconsistent with how it deals with case, e.g.: $ ls RollUp $ ls -d Rollup Rollup $ ls -d RollUp RollUp $ find . -name Rollup -print $ find . -name RollUp -print ./RollUp So I guess I can understand git also being inconsistent there. But what really got me was the dir being gone on the branch. Is all this expected behavior? Is this not the correct list for a question like this? If not, is there another list that's more appropriate? -- 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] Makefile: respect $LINGUAS variable on selecting .mo files to install
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- On Fri, Sep 14, 2012 at 6:35 PM, Nguyen Thai Ngoc Duy pclo...@gmail.com wrote: We should honor LINGUAS variable on installation. Only languages listed in that variable are installed. Many if not most of projects do that already. And here is a try. Makefile | 4 1 file changed, 4 insertions(+) diff --git a/Makefile b/Makefile index 56301dc..eeba645 100644 --- a/Makefile +++ b/Makefile @@ -2437,7 +2437,11 @@ po/git.pot: $(LOCALIZED_C) pot: po/git.pot +ifdef LINGUAS +POFILES := $(shell sh -c ls $(patsubst %,po/%.po,$(LINGUAS)) 2/dev/null) +else POFILES := $(wildcard po/*.po) +endif MOFILES := $(patsubst po/%.po,po/build/locale/%/LC_MESSAGES/git.mo,$(POFILES)) ifndef NO_GETTEXT -- 1.7.12.403.gce5cf6f.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: Please pull git-l10n updates for git v1.7.12-146-g16d26
(Dropping translators as they probably are not interested in this) I saw a gnu project does this (I don't remember what project). If we update .po* files with --no-location, we can avoid a lot of diff noises due to line number changes. A typical translator does not care about these lines anyway. Those who do can easily search the string in source files without them. On Thu, Sep 13, 2012 at 5:41 AM, Jiang Xin worldhello@gmail.com wrote: po/TEAMS|3 +- po/de.po| 712 po/git.pot | 684 +++ po/sv.po| 715 po/vi.po| 1767 +++ po/zh_CN.po | 712 6 files changed, 2394 insertions(+), 2199 deletions(-) -- 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: Using Format/export-subst Howto.
Mestnik, Michael J - Eagan, MN - Contractor venit, vidit, dixit 14.09.2012 14:20: I must have missed something reading through the documentation for this. git version 1.7.11.3 $ git check-attr -a -- autorepair.d/AR02_new_rttest.sh autorepair.d/AR02_new_rttest.sh: ident: set autorepair.d/AR02_new_rttest.sh: export-subst: set echo 0..$_expected_tests diag 'Script Version: $Id: 1ca40f8395ea361cc07d2ec1a2961c3df749dc3c $' diag 'By: $Format:%cn$ $Format:%ce$' diag 'At: $Format:%cD$' '$Format:' is processed when creating an archive. It's mentioned with export-subst only under the heading create archive. So, that is as described, I think. I also believe that the documentation could try and better explain under what conditions $Id will be processed, it doesn't seam to happen on commit and even after a checkout this is not updated. It does seam to update during a pull and that's basically all I need. git replaces $Id$... upon checkout. Any byte sequence that begins with $Id: and ends with $ in the worktree file is replaced with $Id$ upon check-in. Now, the there are two problems after you add $Id$ and check-in (commit): - commit does not check out, i.e. your work-tree copy is not updated with expanded $Id$ - Not even git checkout thatFile updates your work-tree copy. The first one could be considered OK, but at least the second one seems to be a bug. Together they create the following problem: Say, you've corrected that problem (rm that file and checkout) and then update your file, add and commit. It will keeping having the old (now wrong) Id expansion. We should do something about this. Michael -- 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] Makefile: respect $LINGUAS variable on selecting .mo files to install
Nguyễn Thái Ngọc Duy venit, vidit, dixit 14.09.2012 14:40: Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- On Fri, Sep 14, 2012 at 6:35 PM, Nguyen Thai Ngoc Duy pclo...@gmail.com wrote: We should honor LINGUAS variable on installation. Only languages listed in that variable are installed. Many if not most of projects do that already. And here is a try. Makefile | 4 1 file changed, 4 insertions(+) diff --git a/Makefile b/Makefile index 56301dc..eeba645 100644 --- a/Makefile +++ b/Makefile @@ -2437,7 +2437,11 @@ po/git.pot: $(LOCALIZED_C) pot: po/git.pot +ifdef LINGUAS +POFILES := $(shell sh -c ls $(patsubst %,po/%.po,$(LINGUAS)) 2/dev/null) +else POFILES := $(wildcard po/*.po) +endif MOFILES := $(patsubst po/%.po,po/build/locale/%/LC_MESSAGES/git.mo,$(POFILES)) ifndef NO_GETTEXT While that may be worthwhile if LINGUAS is some sort of standard I don't think it relates to the discussion at hand. The problem is not the set to choose from but the choice and the specificity of the choice (which parts of the code does it affect). Michael -- 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] clone: fix refspec on --single-branch option
On Fri, Sep 14, 2012 at 1:48 PM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
Who guarantees at this point in the codepath that option_branch is
set when option_single_branch is non-zero? Until we talk with the
remote, clone --single-branch without an explicit --branch will
not learn which branch at the remote we are going to fetch (it will
be their HEAD).
I wonder if this should be more like this:
if (option_single_branch) {
if (option_branch)
Your patch +refs/heads/foo:refs/remotes/origin/foo;
else
HEAD;
} else {
Original +refs/heads/*:refs/remotes/origin/*;
}
That is, clone --single-branch will continue fetching from and
integrating with their HEAD without storing any remote tracking
branch.
Alternatively, if you can move the logic to set up this
configuration further down so that it happens after we talked to the
other side and figured out remote_head_points_at, you could instead
set it up to keep a single remote tracking branch.
That sounds reasonable. I have a question though, what should a user
do when he/she want to fetch all branches again? Messing up with
refspec in config file is not something I would like to do.
Perhaps a heuristic in git-fetch to detect single branch situation
and ignore refspec? We could hint people that refspecs are not
followed when remote has more than one branch. They could either fetch
the another branch explicitly, which turns off the heuristic, or turn
off the advice.
Even if you did so, guess_remote_head() may not find any branch when
the other repository's HEAD is detached, so you would need to decide
what to do in such a case, and fetch and integrate their HEAD
without using any remote tracking branch may be a reasonable thing
to do in such a case.
--
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: inconsistent behavior on mac with case changes
On 09/14/2012 02:37 PM, Larry Martell wrote: On Thu, Sep 13, 2012 at 5:24 PM, Larry Martell larry.mart...@gmail.com wrote: I created a dir on my Mac called Rollup, and pushed it out. Then went to a CentOS box, pulled it, and realized I wanted to call it RollUp (capital U). I renamed it, and pushed out the change. Went back to the Mac and did a pull - it said it created the RollUp dir, but it did not - it was still called Rollup. I reamed it, but status did not pick up the change. Then I checked out a branch that had Rollup, but it was gone there - no Rollup or RollUp. I did a merge and then RollUp was created. I know the Mac is somewhat inconsistent with how it deals with case, e.g.: $ ls RollUp $ ls -d Rollup Rollup $ ls -d RollUp RollUp $ find . -name Rollup -print $ find . -name RollUp -print ./RollUp So I guess I can understand git also being inconsistent there. But what really got me was the dir being gone on the branch. Is all this expected behavior? More or less. Git sees Rollup and RollUp as two different directories, so assuming everything inside it is committed git is free to remove the directory that exists on one branch but not the other when switching branches in order to keep the work tree in sync with the index. Consider this (most output cut away): git init touch base; git add base git commit -m first commit mkdir foo touch foo/lala git add foo/lala git commit -m meh git checkout -b newbranch HEAD^ ls -ld foo ls: cannot access foo.: No such file or directory mkdir bar touch bar/bear git add bar/bear git commit -m rawr git checkout master ls -ld bar ls: cannot access bar.: no such file or directory If git would leave your committed directory in the worktree when you move to a branch that doesn't have it, it would put you in a very weird position where you may have to clear away rubble from someone else, or start depending on code that's not in your branch. So yes, you're seeing the expected behaviour, and OSX is retarded wrt case sensitive filenames. I'd suggest you either reformat your drive to stop using HFS+ or do your development work inside a loopback fs mounted with proper case sensitivity, as there's really no sane way around the problem OSX causes. Is this not the correct list for a question like this? If not, is there another list that's more appropriate? It is, but people don't always spend their days looking for questions to answer. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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: inconsistent behavior on mac with case changes
On Fri, Sep 14, 2012 at 9:48 AM, Andreas Ericsson a...@op5.se wrote: On 09/14/2012 02:37 PM, Larry Martell wrote: On Thu, Sep 13, 2012 at 5:24 PM, Larry Martell larry.mart...@gmail.com wrote: I created a dir on my Mac called Rollup, and pushed it out. Then went to a CentOS box, pulled it, and realized I wanted to call it RollUp (capital U). I renamed it, and pushed out the change. Went back to the Mac and did a pull - it said it created the RollUp dir, but it did not - it was still called Rollup. I reamed it, but status did not pick up the change. Then I checked out a branch that had Rollup, but it was gone there - no Rollup or RollUp. I did a merge and then RollUp was created. I know the Mac is somewhat inconsistent with how it deals with case, e.g.: $ ls RollUp $ ls -d Rollup Rollup $ ls -d RollUp RollUp $ find . -name Rollup -print $ find . -name RollUp -print ./RollUp So I guess I can understand git also being inconsistent there. But what really got me was the dir being gone on the branch. Is all this expected behavior? More or less. Git sees Rollup and RollUp as two different directories, so assuming everything inside it is committed git is free to remove the directory that exists on one branch but not the other when switching branches in order to keep the work tree in sync with the index. Consider this (most output cut away): git init touch base; git add base git commit -m first commit mkdir foo touch foo/lala git add foo/lala git commit -m meh git checkout -b newbranch HEAD^ ls -ld foo ls: cannot access foo.: No such file or directory mkdir bar touch bar/bear git add bar/bear git commit -m rawr git checkout master ls -ld bar ls: cannot access bar.: no such file or directory If git would leave your committed directory in the worktree when you move to a branch that doesn't have it, it would put you in a very weird position where you may have to clear away rubble from someone else, or start depending on code that's not in your branch. So yes, you're seeing the expected behaviour, and OSX is retarded wrt case sensitive filenames. I'd suggest you either reformat your drive to stop using HFS+ or do your development work inside a loopback fs mounted with proper case sensitivity, as there's really no sane way around the problem OSX causes. Thanks for the detailed reply! -- 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] clone: fix refspec on --single-branch option
On Fri, Sep 14, 2012 at 3:10 PM, Nguyen Thai Ngoc Duy pclo...@gmail.com wrote:
On Fri, Sep 14, 2012 at 1:48 PM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
Who guarantees at this point in the codepath that option_branch is
set when option_single_branch is non-zero? Until we talk with the
remote, clone --single-branch without an explicit --branch will
not learn which branch at the remote we are going to fetch (it will
be their HEAD).
I wonder if this should be more like this:
if (option_single_branch) {
if (option_branch)
Your patch +refs/heads/foo:refs/remotes/origin/foo;
else
HEAD;
} else {
Original +refs/heads/*:refs/remotes/origin/*;
}
That is, clone --single-branch will continue fetching from and
integrating with their HEAD without storing any remote tracking
branch.
Alternatively, if you can move the logic to set up this
configuration further down so that it happens after we talked to the
other side and figured out remote_head_points_at, you could instead
set it up to keep a single remote tracking branch.
That sounds reasonable. I have a question though, what should a user
do when he/she want to fetch all branches again? Messing up with
refspec in config file is not something I would like to do.
$ git remote set-branches remote *
Perhaps a heuristic in git-fetch to detect single branch situation
and ignore refspec? We could hint people that refspecs are not
followed when remote has more than one branch. They could either fetch
the another branch explicitly, which turns off the heuristic, or turn
off the advice.
Such an advice when using --single-branch is a good idea, i think.
Something like The remote remote is configured to fetch only branch branch.
If you want to fetch all branches, use git remote set-branches remote *
or something like that.
Even if you did so, guess_remote_head() may not find any branch when
the other repository's HEAD is detached, so you would need to decide
what to do in such a case, and fetch and integrate their HEAD
without using any remote tracking branch may be a reasonable thing
to do in such a case.
--
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: Using Format/export-subst Howto.
Am 9/14/2012 15:03, schrieb Michael J Gruber: git replaces $Id$... upon checkout. Any byte sequence that begins with $Id: and ends with $ in the worktree file is replaced with $Id$ upon check-in. Now, the there are two problems after you add $Id$ and check-in (commit): - commit does not check out, i.e. your work-tree copy is not updated with expanded $Id$ - Not even git checkout thatFile updates your work-tree copy. The first one could be considered OK, but at least the second one seems to be a bug. Together they create the following problem: Say, you've corrected that problem (rm that file and checkout) and then update your file, add and commit. It will keeping having the old (now wrong) Id expansion. If EOL conversion or a clean filter was applied during 'git add file', is the version in the worktree suddenly wrong? Of course, not. I would place $Id$ treatment in the same ball park and declare it as a mistake of the editor that it did not remove the now wrong SHA1 from $Id:$. We should do something about this. Not necessary, IMHO. -- 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: Using Format/export-subst Howto.
-Original Message- From: Johannes Sixt [mailto:j.s...@viscovery.net] Sent: Friday, September 14, 2012 10:07 AM To: Michael J Gruber Cc: Mestnik, Michael J - Eagan, MN - Contractor; git@vger.kernel.org Subject: Re: Using Format/export-subst Howto. Am 9/14/2012 15:03, schrieb Michael J Gruber: git replaces $Id$... upon checkout. Any byte sequence that begins with $Id: and ends with $ in the worktree file is replaced with $Id$ upon check-in. Now, the there are two problems after you add $Id$ and check-in (commit): - commit does not check out, i.e. your work-tree copy is not updated with expanded $Id$ - Not even git checkout thatFile updates your work-tree copy. The first one could be considered OK, but at least the second one seems to be a bug. Together they create the following problem: Say, you've corrected that problem (rm that file and checkout) and then update your file, add and commit. It will keeping having the old (now wrong) Id expansion. If EOL conversion or a clean filter was applied during 'git add file', is the version in the worktree suddenly wrong? Of course, not. I would place $Id$ treatment in the same ball park and declare it as a mistake of the editor that it did not remove the now wrong SHA1 from $Id:$. I think the difference here is that git does not *currently change the OS's LEF. In this case each commit alters the Id and git is the one altering the Id. If git did change the expected/system LEF then it would seam reasonable that it would also be responsible for forward porting files to the new regime. * If git could fix some misguided operating systems into following the correct LEF, that would be great! What I mean is that I agree that git is not the tool to tackle every technical challenge, but I think it should carry though with any decisions it makes and that it should not ignore the effects(or changes) made as a result of **these decisions. ** Any and all, within reason. Cheers! We should do something about this. Not necessary, IMHO. -- Hannes Mike Mestnik, Michael J The ESM Tools Enterprise Systems Monitoring United States Postal Service O: (651) 406-2048 michael.j.mest...@usps.gov itenterprisesystemsmonitor...@usps.gov -- 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: [PATCHv2 3/6] t7810-grep: test multiple --author with --all-match
Michael J Gruber g...@drmicha.warpmail.net writes: Junio C Hamano venit, vidit, dixit 14.09.2012 01:26: ... when --all-match was given from the command line, so that the committer, author and elements on the top-level backbone in pattern form the top-level backbone of the resulting expression to be inspected by the all-match logic. Does this pass the expect-failure test in your [PATCH 5/6]? Just a quick heads up: I merged 38ed8ef (log --grep/--author: honor --all-match honored for multiple --grep patterns, 2012-09-13) from pu into my test branch, and this fixes what I had marked as known failure there. Thanks! Thanks for testing. I still have to figure out the logic, but begin to understand that (OR...) and (AND...) are linewise, and all-match is a bufferwise AND Yes, all-match is about requiring all the top-level nodes to have fired while inspecting the whole file. So between these: $ git grep -e foo --and -e bar $ git grep --all-match -e foo -e bar the former shows lines that has both foo and bar, while the latter shows lines that has either foo or bar but only from files that has both in them (on possibly separate lines). Now, what is *or* ... That is for to show the token we received from the command line parser; the more interesting part is the parsed expression tree, that is mostly formed as a tree with each node labeled with what kind of operation it represents. -- 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] clone: fix refspec on --single-branch option
Nguyen Thai Ngoc Duy pclo...@gmail.com writes: On Fri, Sep 14, 2012 at 1:48 PM, Junio C Hamano gits...@pobox.com wrote: Alternatively, if you can move the logic to set up this configuration further down so that it happens after we talked to the other side and figured out remote_head_points_at, you could instead set it up to keep a single remote tracking branch. That sounds reasonable. I have a question though, what should a user do when he/she want to fetch all branches again? Messing up with refspec in config file is not something I would like to do. You first have to think ;-). I would say there are two kinds of users. - To the simplistic ones who fear the power of configuration, we can simply tell You don't. Use 'single' when you want to keep working with the single branch. If you want full, reclone, and migrate your work from the single one by fetching from it to the full clone before discarding the single one. - To the ones who wants to take the full advantage of flexibility of configuration, we can tell remotes.$name.fetch configuration is your friend. Do whatever you want to do with it, but here are two hints. The hints would cover the case to revert to the default refspec, and the case to add another specific branch. These days, with git config and git remote wrappers, I do not particularly see a need to fear the power of configuration, though. -- 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: Using Format/export-subst Howto.
-Original Message- From: Johannes Sixt [mailto:j.s...@viscovery.net] Sent: Friday, September 14, 2012 10:40 AM To: Mestnik, Michael J - Eagan, MN - Contractor Cc: Michael J Gruber; git@vger.kernel.org Subject: Re: Using Format/export-subst Howto. Am 9/14/2012 17:27, schrieb Mestnik, Michael J - Eagan, MN - Contractor: -Original Message- From: Johannes Sixt If EOL conversion or a clean filter was applied during 'git add file', is the version in the worktree suddenly wrong? Of course, not. I would place $Id$ treatment in the same ball park and declare it as a mistake of the editor that it did not remove the now wrong SHA1 from $Id:$. I think the difference here is that git does not *currently change the OS's LEF. In this case each commit alters the Id and git is the one altering the Id. Maybe you misunderstood $Id$? The value you get there is the blob's SHA1, not the commit's. That is, it does not change on every commit, but only when the file changes. You are right that the value itself is something that is dictated by git's database model, but the change logically happens when the editor modifies the file. (My contribution to this thread should be regarded as food for thought. Personally, I don't mind whether or not and when $Id$ is updated.) Thank you for correcting me, I've always noticed this number doesn't seam to correlate to anything of use for me. However it's been helpful when reading these reports to see what version generated it and that's why I wanted to further expand the information provided... The date and time of the commit are specifically useful to me. -- Hannes Mike Mestnik, Michael J The ESM Tools Enterprise Systems Monitoring United States Postal Service O: (651) 406-2048 michael.j.mest...@usps.gov itenterprisesystemsmonitor...@usps.gov -- 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/RFC] test-lib: add support for colors without tput
For platforms that does not have tput we can still perform coloring
by manually emitting the ANSI control codes. If tput is missing from
$PATH, install a replacement function.
The exact strings has been dumped from a machine that has tput, by
piping the output of tput through 'od -c -An'.
Signed-off-by: Erik Faye-Lund kusmab...@gmail.com
---
I got slightly annoyed that we didn't get colored output from the
tests on Windows, so I decided to fix it.
Hopefully other platforms can benefit from this as well.
I'm not super happy with the condition to enable it. I considered
an environment variable as well, but decided against it because
make -C t from the root does not seem to pick up environment
variables configured in the main Makefile.
Thoughts?
t/test-lib.sh | 14 ++
1 file changed, 14 insertions(+)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 78c4286..7d1b34b 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -129,6 +129,20 @@ export _x05 _x40 _z40 LF
# This test checks if command xyzzy does the right thing...
# '
# . ./test-lib.sh
+
+if ! which tput /dev/null ; then
+ tput () {
+ case $1 in
+ bold)
+ echo -ne \033[1m ;;
+ setaf)
+ echo -ne \033[0;3$2m ;;
+ sgr0)
+ echo -ne \033(\033[m ;;
+ esac
+ }
+fi
+
[ x$ORIGINAL_TERM != xdumb ] (
TERM=$ORIGINAL_TERM
export TERM
--
1.7.11.msysgit.0.5.g0225efe.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] Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption
Recent versions of Linux libc (later than 5.4.23) and glibc (2.x)
include a malloc() implementation which is tunable via environment
variables. When MALLOC_CHECK_ is set, a special (less efficient)
implementation is used which is designed to be tolerant against
simple errors, such as double calls of free() with the same argument,
or overruns of a single byte (off-by-one bugs). When MALLOC_CHECK_
is set to 3, a diagnostic message is printed on stderr
and the program is aborted.
Setting the MALLOC_PERTURB_ environment variable causes the malloc
functions in libc to return memory which has been wiped and clear
memory when it is returned.
Of course this does not affect calloc which always does clear the memory.
The reason for this exercise is, of course, to find code which uses
memory returned by malloc without initializing it and code which uses
code after it is freed. valgrind can do this but it's costly to run.
The MALLOC_PERTURB_ exchanges the ability to detect problems in 100%
of the cases with speed.
The byte value used to initialize values returned by malloc is the byte
value of the environment value. The value used to clear memory is the
bitwise inverse. Setting MALLOC_PERTURB_ to zero disables the feature.
This technique can find hard to detect bugs.
It is therefore suggested to always use this flag (at least temporarily)
when testing out code or a new distribution.
But the test suite can use also valgrind(memcheck) via 'make valgrind'
or 'make GIT_TEST_OPTS=--valgrind'.
Memcheck wraps client calls to malloc(), and puts a red zone on
each end of each block in order to detect access overruns.
Memcheck already detects double free() (up to the limit of the buffer
which remembers pending free()). Thus memcheck subsumes all the
documented coverage of MALLOC_CHECK_.
If MALLOC_CHECK_ is set non-zero when running memcheck, then the
overruns that might be detected by MALLOC_CHECK_ would be overruns
on the wrapped blocks which include the red zones. Thus MALLOC_CHECK_
would be checking memcheck, and not the client. This is not useful,
and actually is wasteful. The only possible [documented] advantage
of using MALLOC_CHECK_ and memcheck together, would be if MALLOC_CHECK_
detected duplicate free() in more cases than memcheck because memcheck's
buffer is too small.
Therefore we don't use MALLOC_CHECK_ and valgrind(memcheck) at the
same time.
Signed-off-by: Elia Pinto gitter.spi...@gmail.com
---
This the third reroll of the original patch.
I redid the patch correcting the export command in a more portable
way thanks to the Junio observation and not setting MALLOC_CHECK_
at the same time we are using valgrind. Added in the commit the reason,
not so simple to find. Hope the better :=)
t/test-lib.sh |9 +
1 file changed, 9 insertions(+)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 78c4286..f34b861 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -93,6 +93,15 @@ export GIT_AUTHOR_EMAIL GIT_AUTHOR_NAME
export GIT_COMMITTER_EMAIL GIT_COMMITTER_NAME
export EDITOR
+# Add libc MALLOC and MALLOC_PERTURB test
+# only if we are not executing the test with valgrind
+expr $GIT_TEST_OPTS : .*\(--valgrind\) /dev/null || {
+ MALLOC_CHECK_=3
+ export MALLOC_CHECK_
+ MALLOC_PERTURB_=$( expr \( $$ % 255 \) + 1)
+ export MALLOC_PERTURB_
+}
+
# Protect ourselves from common misconfiguration to export
# CDPATH into the environment
unset CDPATH
--
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] test-lib: add support for colors without tput
On Fri, Sep 14, 2012 at 6:41 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 78c4286..7d1b34b 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -129,6 +129,20 @@ export _x05 _x40 _z40 LF
# This test checks if command xyzzy does the right thing...
# '
# . ./test-lib.sh
+
+if ! which tput /dev/null ; then
+ tput () {
+ case $1 in
+ bold)
+ echo -ne \033[1m ;;
+ setaf)
+ echo -ne \033[0;3$2m ;;
+ sgr0)
+ echo -ne \033(\033[m ;;
I should of course have checked this earlier, but I find now that
echo -ne isn't portable. So perhaps this on top?
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 7d1b34b..91a1d7b 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -134,11 +134,11 @@ if ! which tput /dev/null ; then
tput () {
case $1 in
bold)
- echo -ne \033[1m ;;
+ printf %b \033[1m ;;
setaf)
- echo -ne \033[0;3$2m ;;
+ printf %b \033[0;3$2m ;;
sgr0)
- echo -ne \033(\033[m ;;
+ printf %b \033(\033[m ;;
esac
}
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/RFC] test-lib: add support for colors without tput
2012/9/14 Erik Faye-Lund kusmab...@gmail.com: On Fri, Sep 14, 2012 at 6:54 PM, Erik Faye-Lund kusmab...@gmail.com wrote: On Fri, Sep 14, 2012 at 6:41 PM, Erik Faye-Lund kusmab...@gmail.com wrote: diff --git a/t/test-lib.sh b/t/test-lib.sh index 78c4286..7d1b34b 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -129,6 +129,20 @@ export _x05 _x40 _z40 LF # This test checks if command xyzzy does the right thing... # ' # . ./test-lib.sh + Nice. But this setting should be check that we have a terminal first isn't ? Some test like this before test X$$TERM != Xdumb \ test -t 1 2/dev/null \ or the inverse logic. This is what automake and popt autogen.sh does. Best Regards -- 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: [PATCHv3 01/11] grep: teach --debug option to dump the parse tree
Michael J Gruber g...@drmicha.warpmail.net writes:
From: Junio C Hamano gits...@pobox.com
Our grep allows complex boolean expressions to be formed to match
each individual line with operators like --and, '(', ')' and --not.
Introduce the --debug option to show the parse tree to help people
who want to debug and enhance it.
Also log learns --debug-grep option to do the same. The command
This was actually a leftover incorrect message.
When we introduce the equivalent of
$ git grep -e foo --and --not \( -e bar -e baz \)
to the log family in some distant future, we may end up having to
disambiguate the --not (which means something completely different
for the log family) meant for the grep part by doing
$ git log --grep=foo --grep-and --grep-not \
--grep-\( --grep=bar --grep=baz --grep-\)
or something like that, and the code says --grep-debug because that
would fit better than --debug-grep.
Other than that, the patch looks good ;-)
--
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] test-lib: add support for colors without tput
2012/9/14 Elia Pinto gitter.spi...@gmail.com:
2012/9/14 Erik Faye-Lund kusmab...@gmail.com:
On Fri, Sep 14, 2012 at 6:54 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Fri, Sep 14, 2012 at 6:41 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 78c4286..7d1b34b 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -129,6 +129,20 @@ export _x05 _x40 _z40 LF
# This test checks if command xyzzy does the right thing...
# '
# . ./test-lib.sh
+
Nice. But this setting should be check that we have a terminal first isn't ?
Some test like this before
test X$$TERM != Xdumb \
test -t 1 2/dev/null \
and in reality this echo use is not portable.
http://ftp.gnu.org/old-gnu/Manuals/autoconf-2.53/html_node/Limitations-of-Builtins.html
In popt 1_17 autogen.sh does
red=; grn=; lgn=; blu=; std=;
test X$$TERM != Xdumb \
test -t 1 2/dev/null \
{ \
red='^[[0;31m'; \
grn='^[[0;32m'; \
lgn='^[[1;32m'; \
blu='^[[1;34m'; \
std='^[[m'; \
}
and
Die(){
color=$red
echo ${color}${_PROGNAME}: Error: $@${std} 2
exit 1
}
Die message here
or the inverse logic. This is what automake and popt autogen.sh does.
Best Regards
--
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] test-lib: add support for colors without tput
On Fri, Sep 14, 2012 at 7:12 PM, Elia Pinto gitter.spi...@gmail.com wrote: 2012/9/14 Elia Pinto gitter.spi...@gmail.com: 2012/9/14 Erik Faye-Lund kusmab...@gmail.com: On Fri, Sep 14, 2012 at 6:54 PM, Erik Faye-Lund kusmab...@gmail.com wrote: On Fri, Sep 14, 2012 at 6:41 PM, Erik Faye-Lund kusmab...@gmail.com wrote: diff --git a/t/test-lib.sh b/t/test-lib.sh index 78c4286..7d1b34b 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -129,6 +129,20 @@ export _x05 _x40 _z40 LF # This test checks if command xyzzy does the right thing... # ' # . ./test-lib.sh + Nice. But this setting should be check that we have a terminal first isn't ? Some test like this before test X$$TERM != Xdumb \ test -t 1 2/dev/null \ and in reality this echo use is not portable. Yeah; I posted a couple of follow-up mails earlier where I had noticed it and changed to printf instead. It seems the testsuite is already using it, so it's probably portable. Thanks a lot for the extra set of eyes :) -- 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: [PATCHv3 06/11] fixup! log: document use of multiple commit limiting options
Michael J Gruber g...@drmicha.warpmail.net writes: Here are a few typo fixes. There is a mix of single and back ticks already before this patch, i.e. ` vs. ' -- I thought we had guidelines for this but don't find them at the moment. Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- Documentation/rev-list-options.txt | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) Thanks, will squash in. In general: - we want to use `exactly this` when writing an item that the user has to exactly spell as in the text, e.g. subcommand names. - from the older days, we use angle bracket as placeholder in synopsis section and in git subcmd -h output, and in the body text, we tend to write like 'this' to italicise in the documentation. I personally find the angle somewhat ugly in the documentation, but we cannot just drop them as the man -Tascii would suffer if we did so. diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt index 57d6c90..c828408 100644 --- a/Documentation/rev-list-options.txt +++ b/Documentation/rev-list-options.txt @@ -6,12 +6,12 @@ special notations explained in the description, additional commit limiting may be applied. Using more options generally further limits the output (e.g. ---since=date1 limits to commits newer than date1, and using it -with --grep=pattern further limits to commits whose log message -has a line that match pattern), unless otherwise noted. +`--since=date1` limits to commits newer than `date1`, and using it +with `--grep=pattern` further limits to commits whose log message +has a line that matches `pattern`), unless otherwise noted. Note that these are applied before commit -ordering and formatting options, such as '--reverse'. +ordering and formatting options, such as `--reverse`. -- @@ -47,7 +47,7 @@ endif::git-rev-list[] Limit the commits output to ones with author/committer header lines that match the specified pattern (regular expression). With more than one `--author=pattern`, - commits whose author match any of the given patterns are + commits whose author matches any of the given patterns are chosen (similarly for multiple `--committer=pattern`). --grep=pattern:: @@ -55,7 +55,7 @@ endif::git-rev-list[] Limit the commits output to ones with log message that matches the specified pattern (regular expression). With more than one `--grep=pattern`, commits whose message - match any of the given patterns are chosen (but see + matches any of the given patterns are chosen (but see `--all-match`). --all-match:: -- 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: [PATCHv3 00/11] rev-list/log: document logic with several limiting options
Thanks for an update. Queued with minimum modification. -- 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: [msysGit] Re: [PATCH/RFC] test-lib: add support for colors without tput
Am 14.09.2012 18:58, schrieb Erik Faye-Lund:
tput () {
case $1 in
bold)
- echo -ne \033[1m ;;
+ printf \033[1m ;;
setaf)
- echo -ne \033[0;3$2m ;;
+ printf \033[0;3$2m ;;
This should be
printf '\033[0;3%sm' $2 ;;
sgr0)
- echo -ne \033(\033[m ;;
+ printf \033(\033[m ;;
esac
}
fi
Did you test this only in rxvt or in CMD as well? (I hadn't time to
test, yet, so I'm asking :-)
-- 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/RFC] test-lib: add support for colors without tput
Erik Faye-Lund kusmab...@gmail.com writes:
On Fri, Sep 14, 2012 at 6:41 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 78c4286..7d1b34b 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -129,6 +129,20 @@ export _x05 _x40 _z40 LF
# This test checks if command xyzzy does the right thing...
# '
# . ./test-lib.sh
+
+if ! which tput /dev/null ; then
+ tput () {
+ case $1 in
+ bold)
+ echo -ne \033[1m ;;
+ setaf)
+ echo -ne \033[0;3$2m ;;
+ sgr0)
+ echo -ne \033(\033[m ;;
I should of course have checked this earlier, but I find now that
echo -ne isn't portable.
Neither is which, no?
--
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: [msysGit] Re: [PATCH/RFC] test-lib: add support for colors without tput
On Fri, Sep 14, 2012 at 7:28 PM, Johannes Sixt j...@kdbg.org wrote:
Am 14.09.2012 18:58, schrieb Erik Faye-Lund:
tput () {
case $1 in
bold)
- echo -ne \033[1m ;;
+ printf \033[1m ;;
setaf)
- echo -ne \033[0;3$2m ;;
+ printf \033[0;3$2m ;;
This should be
printf '\033[0;3%sm' $2 ;;
That's probably a good idea, yeah.
sgr0)
- echo -ne \033(\033[m ;;
+ printf \033(\033[m ;;
esac
}
fi
Did you test this only in rxvt or in CMD as well? (I hadn't time to
test, yet, so I'm asking :-)
I don't have rxvt installed, but it works for me in CMD also.
--
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] test-lib: add support for colors without tput
On Fri, Sep 14, 2012 at 7:30 PM, Junio C Hamano gits...@pobox.com wrote:
Erik Faye-Lund kusmab...@gmail.com writes:
On Fri, Sep 14, 2012 at 6:41 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 78c4286..7d1b34b 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -129,6 +129,20 @@ export _x05 _x40 _z40 LF
# This test checks if command xyzzy does the right thing...
# '
# . ./test-lib.sh
+
+if ! which tput /dev/null ; then
+ tput () {
+ case $1 in
+ bold)
+ echo -ne \033[1m ;;
+ setaf)
+ echo -ne \033[0;3$2m ;;
+ sgr0)
+ echo -ne \033(\033[m ;;
I should of course have checked this earlier, but I find now that
echo -ne isn't portable.
Neither is which, no?
Oooh, right. Thanks for noticing. So I guess I should try to run it
instead. From the POSIX spec, I can't find a way of running it that
guarantees a return-code of 0 without clobbering the console somehow.
Perhaps the best thing is pass no operands, and check for $? == 127 instead?
Something like this?
diff --git a/t/test-lib.sh b/t/test-lib.sh
index a939e19..1433cb3 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -130,7 +130,8 @@ export _x05 _x40 _z40 LF
# '
# . ./test-lib.sh
-if ! which tput /dev/null ; then
+tput /dev/null
+if test $? -eq 127 ; then
tput () {
case $1 in
bold)
--
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] test-lib: add support for colors without tput
On Fri, Sep 14, 2012 at 06:41:45PM +0200, Erik Faye-Lund wrote: diff --git a/t/test-lib.sh b/t/test-lib.sh index 78c4286..7d1b34b 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -129,6 +129,20 @@ export _x05 _x40 _z40 LF # This test checks if command xyzzy does the right thing... # ' # . ./test-lib.sh + +if ! which tput /dev/null ; then Testing the return value of which is not portable (I know, it's insane; SunOS is the common offender). Use type instead. -Peff -- 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] Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test suite for detecting heap corruption
Elia Pinto gitter.spi...@gmail.com writes:
Recent versions of Linux libc (later than 5.4.23) and glibc (2.x)
include a malloc() implementation which is tunable via environment
variables. When MALLOC_CHECK_ is set, a special (less efficient)
implementation is used which is designed to be tolerant against
simple errors, such as double calls of free() with the same argument,
or overruns of a single byte (off-by-one bugs). When MALLOC_CHECK_
is set to 3, a diagnostic message is printed on stderr
and the program is aborted.
...
Signed-off-by: Elia Pinto gitter.spi...@gmail.com
---
This the third reroll of the original patch.
Well written. I have one suggestion and a question, though.
t/test-lib.sh |9 +
1 file changed, 9 insertions(+)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 78c4286..f34b861 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -93,6 +93,15 @@ export GIT_AUTHOR_EMAIL GIT_AUTHOR_NAME
export GIT_COMMITTER_EMAIL GIT_COMMITTER_NAME
export EDITOR
+# Add libc MALLOC and MALLOC_PERTURB test
+# only if we are not executing the test with valgrind
+expr $GIT_TEST_OPTS : .*\(--valgrind\) /dev/null || {
I would write this like
if ! expr $GIT_TEST_OPTS : .* --valgrind /dev/null
then
...
fi
+ MALLOC_CHECK_=3
+ export MALLOC_CHECK_
+ MALLOC_PERTURB_=$( expr \( $$ % 255 \) + 1)
How was this expression chosen? The only effect I can think of to
use a randomly picked value here is to make it impossible to make
the test repeatable and reproducible, so you must have had some
benefit that outweighs the downside, but I cannot think of any.
Wouldn't MALLOC_PERTURB_=165 (i.e. 0xA5, half of the bits in the
byte is set, including the MSB, and is an odd number) be equally a
good choice without repeatability downside, for example?
Also, doesn't the above give 256 sometimes, which would not fit in a
byte?
+ export MALLOC_PERTURB_
+}
+
# Protect ourselves from common misconfiguration to export
# CDPATH into the environment
unset CDPATH
--
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] test-lib: add support for colors without tput
On Fri, Sep 14, 2012 at 7:44 PM, Jeff King p...@peff.net wrote: On Fri, Sep 14, 2012 at 06:41:45PM +0200, Erik Faye-Lund wrote: diff --git a/t/test-lib.sh b/t/test-lib.sh index 78c4286..7d1b34b 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -129,6 +129,20 @@ export _x05 _x40 _z40 LF # This test checks if command xyzzy does the right thing... # ' # . ./test-lib.sh + +if ! which tput /dev/null ; then Testing the return value of which is not portable (I know, it's insane; SunOS is the common offender). Use type instead. Junio already noticed it, and I suggested a fix that involved running it. However, I like your fix much better, thanks :) -- 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: [PATCHv3 09/11] t7810-grep: test multiple --author with --all-match
Michael J Gruber g...@drmicha.warpmail.net writes:
--all-match is ignored for author matching on purpose.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
It is more like --all-match is about --grep and does not interact
with --author or --committer at all. At least with the recent fix.
t/t7810-grep.sh | 8
1 file changed, 8 insertions(+)
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index b841909..be81d96 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -513,6 +513,14 @@ test_expect_success 'log with multiple --author uses
union' '
test_cmp expect actual
'
+test_expect_success 'log --all-match with multiple --author still uses
union' '
+ git log --all-match --author=Thor --author=Aster --format=%s
actual
+ {
+ echo third echo second echo initial
+ } expect
+ test_cmp expect actual
+'
+
test_expect_success 'log with --grep and multiple --author uses all-match' '
git log --author=Thor --author=Night --grep=i --format=%s actual
{
--
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: [PATCHv3 11/11] t7810-grep: test --all-match with multiple --grep and --author options
Michael J Gruber g...@drmicha.warpmail.net writes:
--all-match is ignored with multiple author options on purpose but
requires all --grep to be matched on some line.
It is more like the behaviour of --all-match to tie more than one --grep
used to be broken when --author or --committer is used.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
t/t7810-grep.sh | 20
1 file changed, 20 insertions(+)
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index f6edb4d..b5c488e 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -531,6 +531,16 @@ test_expect_success 'log --grep --grep --author takes
union of greps and interse
test_cmp expect actual
'
+test_expect_success 'log ---all-match -grep --author --author still takes
union of authors and intersects with grep' '
+ # grep matches only initial and third
+ # author matches all but second
+ git log --all-match --author=Thor --author=Night --grep=i
--format=%s actual
+ {
+ echo third echo initial
+ } expect
+ test_cmp expect actual
+'
+
test_expect_success 'log --grep --author --author takes union of authors and
intersects with grep' '
# grep matches only initial and third
# author matches all but second
@@ -541,6 +551,16 @@ test_expect_success 'log --grep --author --author takes
union of authors and int
test_cmp expect actual
'
+test_expect_success 'log --all-match --grep --grep --author takes
intersection' '
+ # grep matches only third
+ # author matches only initial and third
+ git log --all-match --author=A U Thor --grep=i --grep=r --format=%s
actual
+ {
+ echo third
+ } expect
+ test_cmp expect actual
+'
+
test_expect_success 'grep with CE_VALID file' '
git update-index --assume-unchanged t/t
rm t/t
--
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] test-lib: add support for colors without tput
Erik Faye-Lund kusmab...@gmail.com writes: Neither is which, no? Oooh, right. Thanks for noticing. So I guess I should try to run it instead. From the POSIX spec,... If you assume POSIX.1, there is type. $ type frotz ; echo $? frotz is /usr/games/frotz 0 $ type frobnitz ; echo $? bash: type: frobnitz: not found 1 -- 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
[PATCHv2] clone: fix refspec on --single-branch option
After a repo was cloned with the --single-branch
option, the configured refspec looks like
+refs/heads/*:refs/remotes/origin/*.
After fetching from this repo again, it'll receive
all refs instead of just the ref from the single
branch. Fixing this by configure exactly the ref
of the branch the user specified in the git clone
command.
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
Alternatively, if you can move the logic to set up this
configuration further down so that it happens after we talked to the
other side and figured out remote_head_points_at, you could instead
set it up to keep a single remote tracking branch.
Even if you did so, guess_remote_head() may not find any branch when
the other repository's HEAD is detached, so you would need to decide
what to do in such a case, and fetch and integrate their HEAD
without using any remote tracking branch may be a reasonable thing
to do in such a case.
This second version now covers also the --single-branch
option when it was called without --branch. It also covers
the detached HEAD case.
I've tested all the use-cases that have been described above and it works
as expected with this patch. But there's just one thing. It fetches
also all the tags even if they're not on this branch. I'm still in the
learning process, perhaps someone else can fix this problem or point
me to the reason.
I think it comes from transport_fetch_refs(transport, mapped_refs);
on line 813 which is called with a full +refs/heads/*:refs/remotes/origin/*
refspec. Thanks
builtin/clone.c | 41 +++--
1 Datei geändert, 27 Zeilen hinzugefügt(+), 14 Zeilen entfernt(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index 5e8f3ba..3ddf5ab 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -755,20 +755,6 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
}
strbuf_addf(value, +%s*:%s*, src_ref_prefix, branch_top.buf);
-
- if (option_mirror || !option_bare) {
- /* Configure the remote */
- strbuf_addf(key, remote.%s.fetch, option_origin);
- git_config_set_multivar(key.buf, value.buf, ^$, 0);
- strbuf_reset(key);
-
- if (option_mirror) {
- strbuf_addf(key, remote.%s.mirror, option_origin);
- git_config_set(key.buf, true);
- strbuf_reset(key);
- }
- }
-
strbuf_addf(key, remote.%s.url, option_origin);
git_config_set(key.buf, repo);
strbuf_reset(key);
@@ -853,6 +839,33 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
refs/heads/master);
}
+ if (option_mirror || !option_bare) {
+ strbuf_reset(value);
+ if (option_single_branch) {
+ if (option_branch)
+ strbuf_addf(value, +%s%s:%s%s,
src_ref_prefix, option_branch,
+ branch_top.buf, option_branch);
+ else if (remote_head_points_at)
+ strbuf_addf(value, +%s:%s%s,
our_head_points_at-name,
+
branch_top.buf, prettify_refname(remote_head_points_at-name));
+ } else {
+ strbuf_addf(value, +%s*:%s*, src_ref_prefix,
branch_top.buf);
+ }
+ /* Configure the remote */
+ if (value.len) {
+ strbuf_reset(key);
+ strbuf_addf(key, remote.%s.fetch, option_origin);
+ git_config_set_multivar(key.buf, value.buf, ^$, 0);
+ strbuf_reset(key);
+
+ if (option_mirror) {
+ strbuf_addf(key, remote.%s.mirror,
option_origin);
+ git_config_set(key.buf, true);
+ strbuf_reset(key);
+ }
+ }
+ }
+
if (is_local)
clone_local(path, git_dir);
else if (refs complete_refs_before_fetch)
--
1.7.12.395.g6b149ce.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] Add diff.context option to specify default context
This adds a diff.context config option to allow specifying the number of lines of context. This is similar to Mercurial's 'unified' option. add-context-option Description: Binary data
Re: [PATCH] clone: fix refspec on --single-branch option
Junio C Hamano gits...@pobox.com writes:
Alternatively, if you can move the logic to set up this
configuration further down so that it happens after we talked to the
other side and figured out remote_head_points_at, you could instead
set it up to keep a single remote tracking branch.
Even if you did so, guess_remote_head() may not find any branch when
the other repository's HEAD is detached, so you would need to decide
what to do in such a case, and fetch and integrate their HEAD
without using any remote tracking branch may be a reasonable thing
to do in such a case.
Along the lines of this, perhaps.
builtin/clone.c | 16
1 file changed, 16 insertions(+)
diff --git i/builtin/clone.c w/builtin/clone.c
index 5e8f3ba..c9e099d 100644
--- i/builtin/clone.c
+++ w/builtin/clone.c
@@ -853,6 +853,22 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
refs/heads/master);
}
+ if (option_single_branch) {
+ /* Fix up the refspec for fetch */
+ strbuf_reset(value);
+ if (!remote_head_points_at)
+ strbuf_addf(value, HEAD);
+ else
+ strbuf_addf(value, %s:%s%s,
+ remote_head_points_at-name,
+ branch_top.buf,
+ skip_prefix(remote_head_points_at-name,
refs/heads/));
+
+ strbuf_reset(key);
+ strbuf_addf(key, remote.%s.fetch, option_origin);
+ git_config_set_multivar(key.buf, value.buf, NULL, 1);
+ }
+
if (is_local)
clone_local(path, git_dir);
else if (refs complete_refs_before_fetch)
--
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: [msysGit] Re: [PATCH/RFC] test-lib: add support for colors without tput
Am 14.09.2012 20:11, schrieb Erik Faye-Lund: On Fri, Sep 14, 2012 at 7:28 PM, Johannes Sixt j...@kdbg.org wrote: printf '\033[0;3%sm' $2 ;; Is there a reason for %s rather than %d? It seem it only takes integers,.. No reason. I just mechanically converted your original expression. But there is no reason for my conversion, either, if it can be more or less guaranteed that no arbitrary strings are passed in $2. -- 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: Suggestions for What's cooking
From: Junio C Hamano gits...@pobox.com Sent: Friday, September 14, 2012 5:47 AM Junio C Hamano gits...@pobox.com writes: I've played with both and have prepared patches to Reintegrate and cook (both in the 'todo' branch). Will play with the changes a bit more and then decide. So here is how tonight's What's cooking may look like with extra indentation and blank lines. The tools that read this file to help my workflow have been minimally adjusted. I am hoping that the updates to them I made were enough to make the format tweak not to negatively affect me, and so far things are going smoothly, but I may find some corner cases later. Knock wood... -- 8 -- snip +1. It looks good even when printed with a proportional width font. -- 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] remote-helper: allow fetch to discover sha1 later
On Thu, Sep 13, 2012 at 11:10:26PM -0700, Junio C Hamano wrote: I do not think it is a good idea to allow such a helper to claim that it supports fetch capability, for at least two reasons: * Being able to list is essential for fetch based helpers. think, far from arbitrary. ... Oh, I don't mean to change the semantics of the list command at all. What I thought seemed arbitrary was limiting the *fetch* command to refs with pre-known sha1s. Any list-time optimization in place or possible for such refs wouldn't be affected. (In light of this, specifying a new sha1 for a ref which already had one in the list should probably be an error rather than a warning. I'll update this in the next version and make it clear that a ref message must only be issued for refs reported without a sha1.) * Existing versions of git that can drive remote helpers that claim to have fetch capability are not prepared to accept an unknown refs protocol message from the helper, so a helper written for your new semantics of fetch capability will not work with them. ... I see. I didn't realize that new helper + old Git client is a supported combination. Still, hear me out. 1. A new helper must only send a ref message when git asks for a ref without a known sha1. 2. Asking for a ref without a known sha1 is unsupported, according to git-remote-helpers.txt: Only objects which were reported in the ref list with a sha1 may be fetched [with fetch]. 3. Furthermore, asking for a ref without a known sha1 *already* breaks in existing versions of git with current handlers: $ git fetch testfetch::../git1 foo fatal: bad object error: testfetch::../git1 did not send all necessary objects Compare - existing version of git, with a new handler: $ git fetch testref::../git1 foo warning: testref unexpectedly said: 'ref 0f31snip refs/heads/foo' fatal: bad object error: testref::../git1 did not send all necessary objects So the proposed change doesn't break anything that isn't already broken. :) That said, if you're still not sold, a new capability is fine. Though I think it can be done without it, I'm certainly not opposed to adding one. -- 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: Using Format/export-subst Howto.
Michael J Gruber g...@drmicha.warpmail.net writes: you need to rm file git checkout file). If the user has to update $Id$ to match the current sha1 (by remembering to do a more forceful checkout than checkout -f) then one half of that feature is useless. As if there is any value in $Id$ _feature_. It's a checkbox item, nothing more ;-). -- 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: Using Format/export-subst Howto.
Junio C Hamano gits...@pobox.com writes: Michael J Gruber g...@drmicha.warpmail.net writes: you need to rm file git checkout file). If the user has to update $Id$ to match the current sha1 (by remembering to do a more forceful checkout than checkout -f) then one half of that feature is useless. As if there is any value in $Id$ _feature_. It's a checkbox item, nothing more ;-). Having said that, I think you could do something along this line (I am thinking aloud, so there may be leaps in the logic below). * Introduce a new on-disk flag in the index. Call it X. After entry.c:write_entry() writes it out to the working tree, this flag is cleared. And this codepath is the only place that clears this flag. * When applying a clean filter (from here on, everything that breaks byte-for-byte identity between the copy on the working tree and the contents that is hashed and stored in the object store are considered clean filter, including CRLF-LF and ident), internally apply the corresponding smudge filter to the cleaned result and compare it with the original input we obtained from the working tree. If they differ, flip the X bit on for the path in the index. * When checkout and any potential callers of write_entry() decide whether it is worth calling write_entry() [*1*], consider any path with the X bit on as dirty and call write_entry(). You have to be very careful when designing the third point, though. There will now be two kinds of the working tree file is different from the version registerd in the index once you do the above. Different only because of clean-smudge roundtrip comparison, and different because it does have a real local modification. The former must be considered no local modification for the purpose of merges and branch switching (otherwise you will get cannot merge, you have local modifications error). [Footnote] *1* This currently is done primarily with ie_match_stat(), that essentially is Does the result of applying 'clean' to the working tree contents match what is registered to the index? Do not bother doing this check over and over again once you checked this until the file in the working tree is modified again. -- 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] Revert diffstat back to English
On Fri, Sep 14, 2012 at 11:54 PM, Junio C Hamano ju...@pobox.com wrote: Junio C Hamano gits...@pobox.com writes: Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: This reverts the i18n part of 7f81463 (Use correct grammar in diffstat summary line - 2012-02-01) but still keeps the grammar correctness for English. It also reverts b354f11 (Fix tests under GETTEXT_POISON on diffstat - 2012-08-27). The result is diffstat always in English for all commands. This helps stop users from accidentally sending localized format-patch'd patches. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com Why am I getting this from t3300? --- expected2012-09-14 16:43:09.0 + +++ current 2012-09-14 16:43:09.0 + @@ -1,2 +1,2 @@ tabs\t,\ (dq) and spaces - 1 file changed, 0 insertions(+), 0 deletions(-) + 1 files changed, 0 insertion(+), 0 deletion(-) Ah, your rewrite of Q_() is wrong. Will squash the attached in before queueing this for maint. Arghhh I found that and fixed it, but probably sent an old version. Thanks. -- 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
A huge update of git.pot is coming with 825 new, 24 removed messages
Dear l10n team members, New git.pot is generated from v1.7.12-437-g1084f in the master branch. l10n: Update git.pot (825 new, 24 removed messages) Generate po/git.pot from v1.7.12-437-g1084f with these i18n update(s): * i18n: mark more index-pack strings for translation * i18n: write-tree: mark parseopt strings for translation * i18n: verify-tag: mark parseopt strings for translation * i18n: verify-pack: mark parseopt strings for translation * i18n: update-server-info: mark parseopt strings for translation * i18n: update-ref: mark parseopt strings for translation * i18n: update-index: mark parseopt strings for translation * i18n: tag: mark parseopt strings for translation * i18n: symbolic-ref: mark parseopt strings for translation * i18n: show-ref: mark parseopt strings for translation * i18n: show-branch: mark parseopt strings for translation * i18n: shortlog: mark parseopt strings for translation * i18n: rm: mark parseopt strings for translation * i18n: revert, cherry-pick: mark parseopt strings for translation * i18n: rev-parse: mark parseopt strings for translation * i18n: reset: mark parseopt strings for translation * i18n: rerere: mark parseopt strings for translation * i18n: status: mark parseopt strings for translation * i18n: replace: mark parseopt strings for translation * i18n: remote: mark parseopt strings for translation * i18n: read-tree: mark parseopt strings for translation * i18n: push: mark parseopt strings for translation * i18n: prune: mark parseopt strings for translation * i18n: prune-packed: mark parseopt strings for translation * i18n: pack-refs: mark parseopt strings for translation * i18n: pack-objects: mark parseopt strings for translation * i18n: notes: mark parseopt strings for translation * i18n: name-rev: mark parseopt strings for translation * i18n: mv: mark parseopt strings for translation * i18n: mktree: mark parseopt strings for translation * i18n: merge: mark parseopt strings for translation * i18n: merge-file: mark parseopt strings for translation * i18n: merge-base: mark parseopt strings for translation * i18n: ls-tree: mark parseopt strings for translation * i18n: ls-files: mark parseopt strings for translation * i18n: log: mark parseopt strings for translation * i18n: init-db: mark parseopt strings for translation * i18n: help: mark parseopt strings for translation * i18n: hash-object: mark parseopt strings for translation * i18n: grep: mark parseopt strings for translation * i18n: gc: mark parseopt strings for translation * i18n: fsck: mark parseopt strings for translation * i18n: format-patch: mark parseopt strings for translation * i18n: for-each-ref: mark parseopt strings for translation * i18n: fmt-merge-msg: mark parseopt strings for translation * i18n: fetch: mark parseopt strings for translation * i18n: fast-export: mark parseopt strings for translation * i18n: describe: mark parseopt strings for translation * i18n: config: mark parseopt strings for translation * i18n: count-objects: mark parseopt strings for translation * i18n: commit: mark parseopt strings for translation * i18n: column: mark parseopt strings for translation * i18n: clone: mark parseopt strings for translation * i18n: clean: mark parseopt strings for translation * i18n: cherry: mark parseopt strings for translation * i18n: checkout: mark parseopt strings for translation * i18n: checkout-index: mark parseopt strings for translation * i18n: check-attr: mark parseopt strings for translation * i18n: cat-file: mark parseopt strings for translation * i18n: branch: mark parseopt strings for translation * i18n: blame: mark parseopt strings for translation * i18n: add: mark parseopt strings for translation * i18n: bisect--helper: mark parseopt strings for translation * i18n: archive: mark parseopt strings for translation * i18n: mark style in OPT_COLUMN() for translation Signed-off-by: Jiang Xin worldhello@gmail.com It's time for a new round of translation. * Fetch new commits from git://github.com/git-l10n/git-po * Update your XX.po according to the new git.pot file. * Start your translation and review your commits inside your l10n team. * Send a pull request to git-l10n/git-po on GitHub. -- Jiang Xin -- 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: Please pull git-l10n updates for git v1.7.12-146-g16d26
On Sat, Sep 15, 2012 at 8:34 AM, Jiang Xin worldhello@gmail.com wrote: 2012/9/14 Nguyen Thai Ngoc Duy pclo...@gmail.com: (Dropping translators as they probably are not interested in this) I saw a gnu project does this (I don't remember what project). If we update .po* files with --no-location, we can avoid a lot of diff noises due to line number changes. A typical translator does not care about these lines anyway. Those who do can easily search the string in source files without them. I believe some translators need these location infomation to find the context. Unless you are also a git developer, I doubt if sha1_file.c makes sense to any translators. In my 8 years of being translator/programmer to open source world, I rarely look at those lines (though I admit I do). A slightly modified suggestion is just drop line number, not the file name, but xgettext does not support that, unfortunately. -- 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
