* Re: [PATCH] Remove misleading date form api-index-skel.txt
From: Junio C Hamano @ 2012-12-16 19:59 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Thomas Ackermann, git
In-Reply-To: <m2ip828jtx.fsf@linux-m68k.org>
Andreas Schwab <schwab@linux-m68k.org> writes:
> s/form/from/
>
> Andreas.
Thanks; will apply.
^ permalink raw reply
* [PATCH v2 2/2] Makefile: detect when PYTHON_PATH changes
From: Christian Couder @ 2012-12-16 19:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
When make is run, the python scripts are created from *.py files that
are changed to use the python given by PYTHON_PATH. And PYTHON_PATH
is set by default to /usr/bin/python on Linux.
This is nice except when you run make another time setting a
different PYTHON_PATH, because, as the python scripts have already
been created, make finds nothing to do.
The goal of this patch is to detect when the PYTHON_PATH changes and
to create the python scripts again when this happens. To do that we
use the same trick that is done to track other variables like prefix,
flags, tcl/tk path and shell path. We update a GIT-PYTHON-VARS file
with the PYTHON_PATH and check if it changed.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
.gitignore | 1 +
Makefile | 16 ++++++++++++++--
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/.gitignore b/.gitignore
index 6d69ae1..086c5af 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,6 +2,7 @@
/GIT-CFLAGS
/GIT-LDFLAGS
/GIT-PREFIX
+/GIT-PYTHON-VARS
/GIT-SCRIPT-DEFINES
/GIT-USER-AGENT
/GIT-VERSION-FILE
diff --git a/Makefile b/Makefile
index 585b2eb..7db8445 100644
--- a/Makefile
+++ b/Makefile
@@ -2245,7 +2245,7 @@ $(patsubst %.perl,%,$(SCRIPT_PERL)) git-instaweb: % : unimplemented.sh
endif # NO_PERL
ifndef NO_PYTHON
-$(patsubst %.py,%,$(SCRIPT_PYTHON)): GIT-CFLAGS GIT-PREFIX
+$(patsubst %.py,%,$(SCRIPT_PYTHON)): GIT-CFLAGS GIT-PREFIX GIT-PYTHON-VARS
$(patsubst %.py,%,$(SCRIPT_PYTHON)): % : %.py
$(QUIET_GEN)$(RM) $@ $@+ && \
INSTLIBDIR=`MAKEFLAGS= $(MAKE) -C git_remote_helpers -s \
@@ -2624,6 +2624,18 @@ ifdef GIT_PERF_MAKE_OPTS
@echo GIT_PERF_MAKE_OPTS=\''$(subst ','\'',$(subst ','\'',$(GIT_PERF_MAKE_OPTS)))'\' >>$@
endif
+### Detect Python interpreter path changes
+ifndef NO_PYTHON
+TRACK_PYTHON = $(subst ','\'',-DPYTHON_PATH='$(PYTHON_PATH_SQ)')
+
+GIT-PYTHON-VARS: FORCE
+ @VARS='$(TRACK_PYTHON)'; \
+ if test x"$$VARS" != x"`cat $@ 2>/dev/null`" ; then \
+ echo 1>&2 " * new Python interpreter location"; \
+ echo "$$VARS" >$@; \
+ fi
+endif
+
test_bindir_programs := $(patsubst %,bin-wrappers/%,$(BINDIR_PROGRAMS_NEED_X) $(BINDIR_PROGRAMS_NO_X) $(TEST_PROGRAMS_NEED_X))
all:: $(TEST_PROGRAMS) $(test_bindir_programs)
@@ -2899,7 +2911,7 @@ ifndef NO_TCLTK
$(MAKE) -C git-gui clean
endif
$(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-LDFLAGS GIT-BUILD-OPTIONS
- $(RM) GIT-USER-AGENT GIT-PREFIX GIT-SCRIPT-DEFINES
+ $(RM) GIT-USER-AGENT GIT-PREFIX GIT-SCRIPT-DEFINES GIT-PYTHON-VARS
.PHONY: all install profile-clean clean strip
.PHONY: shell_compatibility_test please_set_SHELL_PATH_to_a_more_modern_shell
--
1.8.1.rc1.2.g8740035
^ permalink raw reply related
* [PATCH v2 1/2] Makefile: remove tracking of TCLTK_PATH
From: Christian Couder @ 2012-12-16 19:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
It looks like we are tracking the value of TCLTK_PATH in the main
Makefile for no good reason, as this is done in git-gui too and the
GIT-GUI-VARS is not used in the Makefile.
This patch removes the useless code used to do this tracking.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
.gitignore | 1 -
Makefile | 14 +-------------
2 files changed, 1 insertion(+), 14 deletions(-)
diff --git a/.gitignore b/.gitignore
index f702415..6d69ae1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,7 +1,6 @@
/GIT-BUILD-OPTIONS
/GIT-CFLAGS
/GIT-LDFLAGS
-/GIT-GUI-VARS
/GIT-PREFIX
/GIT-SCRIPT-DEFINES
/GIT-USER-AGENT
diff --git a/Makefile b/Makefile
index 4ad6fbd..585b2eb 100644
--- a/Makefile
+++ b/Makefile
@@ -2624,18 +2624,6 @@ ifdef GIT_PERF_MAKE_OPTS
@echo GIT_PERF_MAKE_OPTS=\''$(subst ','\'',$(subst ','\'',$(GIT_PERF_MAKE_OPTS)))'\' >>$@
endif
-### Detect Tck/Tk interpreter path changes
-ifndef NO_TCLTK
-TRACK_VARS = $(subst ','\'',-DTCLTK_PATH='$(TCLTK_PATH_SQ)')
-
-GIT-GUI-VARS: FORCE
- @VARS='$(TRACK_VARS)'; \
- if test x"$$VARS" != x"`cat $@ 2>/dev/null`" ; then \
- echo 1>&2 " * new Tcl/Tk interpreter location"; \
- echo "$$VARS" >$@; \
- fi
-endif
-
test_bindir_programs := $(patsubst %,bin-wrappers/%,$(BINDIR_PROGRAMS_NEED_X) $(BINDIR_PROGRAMS_NO_X) $(TEST_PROGRAMS_NEED_X))
all:: $(TEST_PROGRAMS) $(test_bindir_programs)
@@ -2910,7 +2898,7 @@ ifndef NO_TCLTK
$(MAKE) -C gitk-git clean
$(MAKE) -C git-gui clean
endif
- $(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-LDFLAGS GIT-GUI-VARS GIT-BUILD-OPTIONS
+ $(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-LDFLAGS GIT-BUILD-OPTIONS
$(RM) GIT-USER-AGENT GIT-PREFIX GIT-SCRIPT-DEFINES
.PHONY: all install profile-clean clean strip
--
1.8.1.rc1.2.g8740035
^ permalink raw reply related
* [PATCH 2/3] Documentation: move support for old compilers to CodingGuidelines
From: Adam Spiers @ 2012-12-16 19:36 UTC (permalink / raw)
To: git list
In-Reply-To: <1355686561-1057-1-git-send-email-git@adamspiers.org>
The "Try to be nice to older C compilers" text is clearly a guideline
to be borne in mind whilst coding rather than when submitting patches.
Signed-off-by: Adam Spiers <git@adamspiers.org>
---
Documentation/CodingGuidelines | 8 ++++++++
Documentation/SubmittingPatches | 13 -------------
2 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 57da6aa..69f7e9b 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -112,6 +112,14 @@ For C programs:
- We try to keep to at most 80 characters per line.
+ - We try to support a wide range of C compilers to compile git with,
+ including old ones. That means that you should not use C99
+ initializers, even if a lot of compilers grok it.
+
+ - Variables have to be declared at the beginning of the block.
+
+ - NULL pointers shall be written as NULL, not as 0.
+
- When declaring pointers, the star sides with the variable
name, i.e. "char *string", not "char* string" or
"char * string". This makes it easier to understand code
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index c107cb1..c34c9d1 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -127,19 +127,6 @@ in templates/hooks--pre-commit. To help ensure this does not happen,
run git diff --check on your changes before you commit.
-(1a) Try to be nice to older C compilers
-
-We try to support a wide range of C compilers to compile
-git with. That means that you should not use C99 initializers, even
-if a lot of compilers grok it.
-
-Also, variables have to be declared at the beginning of the block
-(you can check this with gcc, using the -Wdeclaration-after-statement
-option).
-
-Another thing: NULL pointers shall be written as NULL, not as 0.
-
-
(2) Generate your patch using git tools out of your commits.
git based diff tools generate unidiff which is the preferred format.
--
1.7.12.1.396.g53b3ea9
^ permalink raw reply related
* [PATCH 3/3] Makefile: use -Wdeclaration-after-statement if supported
From: Adam Spiers @ 2012-12-16 19:36 UTC (permalink / raw)
To: git list
In-Reply-To: <1355686561-1057-1-git-send-email-git@adamspiers.org>
CodingGuidelines requests that code should be nice to older C compilers.
Since modern gcc can warn on code written using newer dialects such as C99,
it makes sense to take advantage of this by auto-detecting this capability
and enabling it when found.
Signed-off-by: Adam Spiers <git@adamspiers.org>
---
If we adopt this approach, it may make sense to enable other flags
where available (e.g. -Wzero-as-null-pointer-constant, maybe even
-ansi). In that case, something like this might be a more efficient
way of writing it:
GCC_FLAGS=-Wdeclaration-after-statement,-Wanother-flag,-Wand-another
GCC_FLAGS_REGEXP=$(shell echo $(GCC_FLAGS) | sed 's/,/\\|/g')
GCC_SUPPORTED_FLAGS=$(shell cc --help -v 2>&1 | \
sed -n '/.* \($(GCC_FLAGS_REGEXP)\) .*/{s//\1/;p}')
Makefile | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index a49d1db..aae70d4 100644
--- a/Makefile
+++ b/Makefile
@@ -331,8 +331,13 @@ endif
# CFLAGS and LDFLAGS are for the users to override from the command line.
CFLAGS = -g -O2 -Wall
+GCC_DECL_AFTER_STATEMENT = \
+ $(shell $(CC) --help -v 2>&1 | \
+ grep -q -- -Wdeclaration-after-statement && \
+ echo -Wdeclaration-after-statement)
+GCC_FLAGS = $(GCC_DECL_AFTER_STATEMENT)
+ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS) $(GCC_FLAGS)
LDFLAGS =
-ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS)
ALL_LDFLAGS = $(LDFLAGS)
STRIP ?= strip
--
1.7.12.1.396.g53b3ea9
^ permalink raw reply related
* [PATCH 1/3] SubmittingPatches: add convention of prefixing commit messages
From: Adam Spiers @ 2012-12-16 19:35 UTC (permalink / raw)
To: git list
In-Reply-To: <1355686561-1057-1-git-send-email-git@adamspiers.org>
Conscientious newcomers to git development will read SubmittingPatches
and CodingGuidelines, but could easily miss the convention of
prefixing commit messages with a single word identifying the file
or area the commit touches.
Signed-off-by: Adam Spiers <git@adamspiers.org>
---
Documentation/SubmittingPatches | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 0dbf2c9..c107cb1 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -9,6 +9,14 @@ Checklist (and a short version for the impatient):
- the first line of the commit message should be a short
description (50 characters is the soft limit, see DISCUSSION
in git-commit(1)), and should skip the full stop
+ - it is also conventional in most cases to prefix the
+ first line with "area: " where the area is a filename
+ or identifier for the general area of the code being
+ modified, e.g.
+ . archive: ustar header checksum is computed unsigned
+ . git-cherry-pick.txt: clarify the use of revision range notation
+ (if in doubt which identifier to use, run "git log --no-merges"
+ on the files you are modifying to see the current conventions)
- the body should provide a meaningful commit message, which:
. explains the problem the change tries to solve, iow, what
is wrong with the current code without the change.
--
1.7.12.1.396.g53b3ea9
^ permalink raw reply related
* [PATCH 0/3] Help newbie git developers avoid obvious pitfalls
From: Adam Spiers @ 2012-12-16 19:35 UTC (permalink / raw)
To: git list
In-Reply-To: <7vobl0804s.fsf@alter.siamese.dyndns.org>
I fell into various newbie pitfalls when submitting my first patches
to git, despite my best attempts to adhere to documented guidelines.
This small patch series attempts to reduce the chances of other
developers making the same mistakes I did.
Adam Spiers (3):
SubmittingPatches: add convention of prefixing commit messages
Documentation: move support for old compilers to CodingGuidelines
Makefile: use -Wdeclaration-after-statement if supported
Documentation/CodingGuidelines | 8 ++++++++
Documentation/SubmittingPatches | 21 ++++++++-------------
Makefile | 7 ++++++-
3 files changed, 22 insertions(+), 14 deletions(-)
--
1.7.12.1.396.g53b3ea9
^ permalink raw reply
* Re: [PATCH v6 0/7] make test output coloring more intuitive
From: Adam Spiers @ 2012-12-16 19:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7v8v8xrfnp.fsf@alter.siamese.dyndns.org>
On Sun, Dec 16, 2012 at 6:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Adam Spiers <git@adamspiers.org> writes:
>
>> This series of commits attempts to make test output coloring
>> more intuitive,...
>
> Thanks; I understand that this is to replace the previous one
> b465316 (tests: paint unexpectedly fixed known breakages in bold
> red, 2012-09-19)---am I correct?
Correct. AFAICS I have incorporated all feedback raised in previous
reviews.
> Will take a look; thanks.
Thanks. Sorry again for the delay. I'm now (finally) resuming work
on as/check-ignore.
^ permalink raw reply
* Re: [PATCH v6 0/7] make test output coloring more intuitive
From: Junio C Hamano @ 2012-12-16 18:54 UTC (permalink / raw)
To: Adam Spiers; +Cc: git list
In-Reply-To: <1355682495-22382-1-git-send-email-git@adamspiers.org>
Adam Spiers <git@adamspiers.org> writes:
> This series of commits attempts to make test output coloring
> more intuitive,...
Thanks; I understand that this is to replace the previous one
b465316 (tests: paint unexpectedly fixed known breakages in bold
red, 2012-09-19)---am I correct?
> - red is only used for things which have gone unexpectedly wrong:
> test failures, unexpected test passes, and failures with the
> framework,
>
> - yellow is only used for known breakages,
>
> - green is only used for things which have gone to plan and
> require no further work to be done,
>
> - blue is only used for skipped tests, and
>
> - cyan is used for other informational messages.
OK.
> Since unexpected test passes are no longer treated as passes, the
> summary lines displayed at the end of a test run have enough different
> possible outputs to warrant them being covered in the test framework's
> self-tests. Therefore this series also refactors and extends the
> self-tests.
>
> Adam Spiers (7):
> tests: test number comes first in 'not ok $count - $message'
> tests: paint known breakages in bold yellow
> tests: paint skipped tests in bold blue
> tests: change info messages from yellow/brown to bold cyan
> tests: refactor mechanics of testing in a sub test-lib
> tests: test the test framework more thoroughly
> tests: paint unexpectedly fixed known breakages in bold red
>
> t/t0000-basic.sh | 211 ++++++++++++++++++++++++++++++++++++++++++-------------
> t/test-lib.sh | 25 ++++---
> 2 files changed, 180 insertions(+), 56 deletions(-)
Will take a look; thanks.
^ permalink raw reply
* Re: [PATCH v2] Documentation: don't link to example mail addresses
From: Junio C Hamano @ 2012-12-16 18:48 UTC (permalink / raw)
To: John Keeping; +Cc: Jeff King, git
In-Reply-To: <20121216140029.GE2725@river.lan>
John Keeping <john@keeping.me.uk> writes:
> Email addresses in documentation are converted into mailto: hyperlinks
> in the HTML output and footnotes in man pages. This isn't desirable for
> cases where the address is used as an example and is not valid.
>
> Particularly annoying is the example "jane@laptop.(none)" which appears
> in git-shortlog(1) as "jane@laptop[1].(none)", with note 1 saying:
>
> 1. jane@laptop
> mailto:jane@laptop
>
> Fix this by escaping these email addresses with a leading backslash, to
> prevent Asciidoc expanding them as inline macros.
>
> In the case of mailmap.txt, render the address monospaced so that it
> matches the block examples surrounding that paragraph.
>
> Helped-by: Jeff King <peff@peff.net>
> Signed-off-by: John Keeping <john@keeping.me.uk>
> ---
>
> On Sun, Dec 16, 2012 at 07:04:05AM -0500, Jeff King wrote:
>> Furthermore, the right way to suppress
>> expansion of macros is with a backslash escape.
> [snipped an example]
>> I think it's a little less ugly
>> than the "$$" quoting, but not by much. No clue if one is accepted by
>> more asciidoc versions or not.
>
> From a quick reading of the Asciidoc changelog, I think backslash
> escaping should be supported just as well as "$$" quoting, which leaves
> the minimal patch looking like this.
The patch looks reasonable to me, too. We were bitten by relying on
the description in AsciiDoc documentation (which shows the state of
their latest software) before; between the constructs that work, it
is safer to use the older, more vanilla and more common one.
Thanks.
^ permalink raw reply
* [PATCH v6 6/7] tests: test the test framework more thoroughly
From: Adam Spiers @ 2012-12-16 18:28 UTC (permalink / raw)
To: git list
In-Reply-To: <1355682495-22382-1-git-send-email-git@adamspiers.org>
Add 5 new full test suite runs each with a different number of
passing/failing/broken/fixed tests, in order to ensure that the
correct exit code and output are generated in each case. As before,
these are run in a subdirectory to avoid disrupting the metrics for
the parent tests.
Signed-off-by: Adam Spiers <git@adamspiers.org>
---
t/t0000-basic.sh | 104 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 104 insertions(+)
diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh
index fc5200f..5c1dde0 100755
--- a/t/t0000-basic.sh
+++ b/t/t0000-basic.sh
@@ -79,6 +79,55 @@ check_sub_test_lib_test () {
)
}
+test_expect_success 'pretend we have a fully passing test suite' "
+ run_sub_test_lib_test full-pass '3 passing tests' <<-\\EOF &&
+ for i in 1 2 3; do
+ test_expect_success \"passing test #\$i\" 'true'
+ done
+ test_done
+ EOF
+ check_sub_test_lib_test full-pass <<-\\EOF
+ > ok 1 - passing test #1
+ > ok 2 - passing test #2
+ > ok 3 - passing test #3
+ > # passed all 3 test(s)
+ > 1..3
+ EOF
+"
+
+test_expect_success 'pretend we have a partially passing test suite' "
+ test_must_fail run_sub_test_lib_test \
+ partial-pass '2/3 tests passing' <<-\\EOF &&
+ test_expect_success 'passing test #1' 'true'
+ test_expect_success 'failing test #2' 'false'
+ test_expect_success 'passing test #3' 'true'
+ test_done
+ EOF
+ check_sub_test_lib_test partial-pass <<-\\EOF
+ > ok 1 - passing test #1
+ > not ok 2 - failing test #2
+ # false
+ > ok 3 - passing test #3
+ > # failed 1 among 3 test(s)
+ > 1..3
+ EOF
+"
+
+test_expect_success 'pretend we have a known breakage' "
+ run_sub_test_lib_test failing-todo 'A failing TODO test' <<-\\EOF &&
+ test_expect_success 'passing test' 'true'
+ test_expect_failure 'pretend we have a known breakage' 'false'
+ test_done
+ EOF
+ check_sub_test_lib_test failing-todo <<-\\EOF
+ > ok 1 - passing test
+ > not ok 2 - pretend we have a known breakage # TODO known breakage
+ > # still have 1 known breakage(s)
+ > # passed all remaining 1 test(s)
+ > 1..2
+ EOF
+"
+
test_expect_success 'pretend we have fixed a known breakage' "
run_sub_test_lib_test passing-todo 'A passing TODO test' <<-\\EOF &&
test_expect_failure 'pretend we have fixed a known breakage' 'true'
@@ -92,6 +141,61 @@ test_expect_success 'pretend we have fixed a known breakage' "
EOF
"
+test_expect_success 'pretend we have a pass, fail, and known breakage' "
+ test_must_fail run_sub_test_lib_test \
+ mixed-results1 'mixed results #1' <<-\\EOF &&
+ test_expect_success 'passing test' 'true'
+ test_expect_success 'failing test' 'false'
+ test_expect_failure 'pretend we have a known breakage' 'false'
+ test_done
+ EOF
+ check_sub_test_lib_test mixed-results1 <<-\\EOF
+ > ok 1 - passing test
+ > not ok 2 - failing test
+ > # false
+ > not ok 3 - pretend we have a known breakage # TODO known breakage
+ > # still have 1 known breakage(s)
+ > # failed 1 among remaining 2 test(s)
+ > 1..3
+ EOF
+"
+
+test_expect_success 'pretend we have a mix of all possible results' "
+ test_must_fail run_sub_test_lib_test \
+ mixed-results2 'mixed results #2' <<-\\EOF &&
+ test_expect_success 'passing test' 'true'
+ test_expect_success 'passing test' 'true'
+ test_expect_success 'passing test' 'true'
+ test_expect_success 'passing test' 'true'
+ test_expect_success 'failing test' 'false'
+ test_expect_success 'failing test' 'false'
+ test_expect_success 'failing test' 'false'
+ test_expect_failure 'pretend we have a known breakage' 'false'
+ test_expect_failure 'pretend we have a known breakage' 'false'
+ test_expect_failure 'pretend we have fixed a known breakage' 'true'
+ test_done
+ EOF
+ check_sub_test_lib_test mixed-results2 <<-\\EOF
+ > ok 1 - passing test
+ > ok 2 - passing test
+ > ok 3 - passing test
+ > ok 4 - passing test
+ > not ok 5 - failing test
+ > # false
+ > not ok 6 - failing test
+ > # false
+ > not ok 7 - failing test
+ > # false
+ > not ok 8 - pretend we have a known breakage # TODO known breakage
+ > not ok 9 - pretend we have a known breakage # TODO known breakage
+ > ok 10 - pretend we have fixed a known breakage # TODO known breakage
+ > # fixed 1 known breakage(s)
+ > # still have 2 known breakage(s)
+ > # failed 3 among remaining 8 test(s)
+ > 1..10
+ EOF
+"
+
test_set_prereq HAVEIT
haveit=no
test_expect_success HAVEIT 'test runs if prerequisite is satisfied' '
--
1.7.12.1.396.g53b3ea9
^ permalink raw reply related
* [PATCH v6 7/7] tests: paint unexpectedly fixed known breakages in bold red
From: Adam Spiers @ 2012-12-16 18:28 UTC (permalink / raw)
To: git list
In-Reply-To: <1355682495-22382-1-git-send-email-git@adamspiers.org>
Change color of unexpectedly fixed known breakages to bold red. An
unexpectedly passing test indicates that the test code is somehow
broken or out of sync with the code it is testing. Either way this is
an error which is potentially as bad as a failing test, and as such is
no longer portrayed as a pass in the output.
Signed-off-by: Adam Spiers <git@adamspiers.org>
---
t/t0000-basic.sh | 30 ++++++++++++++++++++++++------
t/test-lib.sh | 13 +++++++++----
2 files changed, 33 insertions(+), 10 deletions(-)
diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh
index 5c1dde0..bd6127f 100755
--- a/t/t0000-basic.sh
+++ b/t/t0000-basic.sh
@@ -134,13 +134,31 @@ test_expect_success 'pretend we have fixed a known breakage' "
test_done
EOF
check_sub_test_lib_test passing-todo <<-\\EOF
- > ok 1 - pretend we have fixed a known breakage # TODO known breakage
- > # fixed 1 known breakage(s)
- > # passed all 1 test(s)
+ > ok 1 - pretend we have fixed a known breakage # TODO known breakage vanished
+ > # 1 known breakage(s) vanished; please update test(s)
> 1..1
EOF
"
+test_expect_success 'pretend we have fixed one of two known breakages (run in sub test-lib)' "
+ run_sub_test_lib_test partially-passing-todos \
+ '2 TODO tests, one passing' <<-\\EOF &&
+ test_expect_failure 'pretend we have a known breakage' 'false'
+ test_expect_success 'pretend we have a passing test' 'true'
+ test_expect_failure 'pretend we have fixed another known breakage' 'true'
+ test_done
+ EOF
+ check_sub_test_lib_test partially-passing-todos <<-\\EOF
+ > not ok 1 - pretend we have a known breakage # TODO known breakage
+ > ok 2 - pretend we have a passing test
+ > ok 3 - pretend we have fixed another known breakage # TODO known breakage vanished
+ > # 1 known breakage(s) vanished; please update test(s)
+ > # still have 1 known breakage(s)
+ > # passed all remaining 1 test(s)
+ > 1..3
+ EOF
+"
+
test_expect_success 'pretend we have a pass, fail, and known breakage' "
test_must_fail run_sub_test_lib_test \
mixed-results1 'mixed results #1' <<-\\EOF &&
@@ -188,10 +206,10 @@ test_expect_success 'pretend we have a mix of all possible results' "
> # false
> not ok 8 - pretend we have a known breakage # TODO known breakage
> not ok 9 - pretend we have a known breakage # TODO known breakage
- > ok 10 - pretend we have fixed a known breakage # TODO known breakage
- > # fixed 1 known breakage(s)
+ > ok 10 - pretend we have fixed a known breakage # TODO known breakage vanished
+ > # 1 known breakage(s) vanished; please update test(s)
> # still have 2 known breakage(s)
- > # failed 3 among remaining 8 test(s)
+ > # failed 3 among remaining 7 test(s)
> 1..10
EOF
"
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 5d9d0fc..b1acdfc 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -308,7 +308,7 @@ test_failure_ () {
test_known_broken_ok_ () {
test_fixed=$(($test_fixed+1))
- say_color "" "ok $test_count - $@ # TODO known breakage"
+ say_color error "ok $test_count - $@ # TODO known breakage vanished"
}
test_known_broken_failure_ () {
@@ -406,13 +406,18 @@ test_done () {
if test "$test_fixed" != 0
then
- say_color pass "# fixed $test_fixed known breakage(s)"
+ say_color error "# $test_fixed known breakage(s) vanished; please update test(s)"
fi
if test "$test_broken" != 0
then
say_color warn "# still have $test_broken known breakage(s)"
- msg="remaining $(($test_count-$test_broken)) test(s)"
+ fi
+ if test "$test_broken" != 0 || test "$test_fixed" != 0
+ then
+ test_remaining=$(( $test_count - $test_broken - $test_fixed ))
+ msg="remaining $test_remaining test(s)"
else
+ test_remaining=$test_count
msg="$test_count test(s)"
fi
case "$test_failure" in
@@ -426,7 +431,7 @@ test_done () {
if test $test_external_has_tap -eq 0
then
- if test $test_count -gt 0
+ if test $test_remaining -gt 0
then
say_color pass "# passed all $msg"
fi
--
1.7.12.1.396.g53b3ea9
^ permalink raw reply related
* [PATCH v6 0/7] make test output coloring more intuitive
From: Adam Spiers @ 2012-12-16 18:28 UTC (permalink / raw)
To: git list
This series of commits attempts to make test output coloring
more intuitive, so that:
- red is only used for things which have gone unexpectedly wrong:
test failures, unexpected test passes, and failures with the
framework,
- yellow is only used for known breakages,
- green is only used for things which have gone to plan and
require no further work to be done,
- blue is only used for skipped tests, and
- cyan is used for other informational messages.
Since unexpected test passes are no longer treated as passes, the
summary lines displayed at the end of a test run have enough different
possible outputs to warrant them being covered in the test framework's
self-tests. Therefore this series also refactors and extends the
self-tests.
Adam Spiers (7):
tests: test number comes first in 'not ok $count - $message'
tests: paint known breakages in bold yellow
tests: paint skipped tests in bold blue
tests: change info messages from yellow/brown to bold cyan
tests: refactor mechanics of testing in a sub test-lib
tests: test the test framework more thoroughly
tests: paint unexpectedly fixed known breakages in bold red
t/t0000-basic.sh | 211 ++++++++++++++++++++++++++++++++++++++++++-------------
t/test-lib.sh | 25 ++++---
2 files changed, 180 insertions(+), 56 deletions(-)
--
1.7.12.1.396.g53b3ea9
^ permalink raw reply
* [PATCH v6 1/7] tests: test number comes first in 'not ok $count - $message'
From: Adam Spiers @ 2012-12-16 18:28 UTC (permalink / raw)
To: git list
In-Reply-To: <1355682495-22382-1-git-send-email-git@adamspiers.org>
The old output to say "not ok - 1 messsage" was working by accident
only because the test numbers are optional in TAP.
Signed-off-by: Adam Spiers <git@adamspiers.org>
---
t/t0000-basic.sh | 4 ++--
t/test-lib.sh | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh
index 562cf41..46ccda3 100755
--- a/t/t0000-basic.sh
+++ b/t/t0000-basic.sh
@@ -189,13 +189,13 @@ test_expect_success 'tests clean up even on failures' "
! test -s err &&
! test -f \"trash directory.failing-cleanup/clean-after-failure\" &&
sed -e 's/Z$//' -e 's/^> //' >expect <<-\\EOF &&
- > not ok - 1 tests clean up even after a failure
+ > not ok 1 - tests clean up even after a failure
> # Z
> # touch clean-after-failure &&
> # test_when_finished rm clean-after-failure &&
> # (exit 1)
> # Z
- > not ok - 2 failure to clean up causes the test to fail
+ > not ok 2 - failure to clean up causes the test to fail
> # Z
> # test_when_finished \"(exit 2)\"
> # Z
diff --git a/t/test-lib.sh b/t/test-lib.sh
index f50f834..d0b236f 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -298,7 +298,7 @@ test_ok_ () {
test_failure_ () {
test_failure=$(($test_failure + 1))
- say_color error "not ok - $test_count $1"
+ say_color error "not ok $test_count - $1"
shift
echo "$@" | sed -e 's/^/# /'
test "$immediate" = "" || { GIT_EXIT_OK=t; exit 1; }
--
1.7.12.1.396.g53b3ea9
^ permalink raw reply related
* [PATCH v6 3/7] tests: paint skipped tests in bold blue
From: Adam Spiers @ 2012-12-16 18:28 UTC (permalink / raw)
To: git list
In-Reply-To: <1355682495-22382-1-git-send-email-git@adamspiers.org>
Skipped tests indicate incomplete test coverage. Whilst this is not a
test failure or other error, it's still not a complete success.
Other testsuite related software like automake, autotest and prove
seem to use blue for skipped tests, so let's follow suit.
Signed-off-by: Adam Spiers <git@adamspiers.org>
---
t/test-lib.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 710f051..220b172 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -212,7 +212,7 @@ then
error)
tput bold; tput setaf 1;; # bold red
skip)
- tput bold; tput setaf 2;; # bold green
+ tput bold; tput setaf 4;; # bold blue
warn)
tput bold; tput setaf 3;; # bold brown/yellow
pass)
--
1.7.12.1.396.g53b3ea9
^ permalink raw reply related
* [PATCH v6 2/7] tests: paint known breakages in bold yellow
From: Adam Spiers @ 2012-12-16 18:28 UTC (permalink / raw)
To: git list
In-Reply-To: <1355682495-22382-1-git-send-email-git@adamspiers.org>
Bold yellow seems a more appropriate color than bold green when
considering the universal traffic lights coloring scheme, where
green conveys the impression that everything's OK, and amber that
something's not quite right.
Likewise, change the color of the summarized total number of known
breakages from bold red to bold yellow to be less alarmist and more
consistent with the above.
Signed-off-by: Adam Spiers <git@adamspiers.org>
---
t/test-lib.sh | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index d0b236f..710f051 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -213,6 +213,8 @@ then
tput bold; tput setaf 1;; # bold red
skip)
tput bold; tput setaf 2;; # bold green
+ warn)
+ tput bold; tput setaf 3;; # bold brown/yellow
pass)
tput setaf 2;; # green
info)
@@ -311,7 +313,7 @@ test_known_broken_ok_ () {
test_known_broken_failure_ () {
test_broken=$(($test_broken+1))
- say_color skip "not ok $test_count - $@ # TODO known breakage"
+ say_color warn "not ok $test_count - $@ # TODO known breakage"
}
test_debug () {
@@ -408,7 +410,7 @@ test_done () {
fi
if test "$test_broken" != 0
then
- say_color error "# still have $test_broken known breakage(s)"
+ say_color warn "# still have $test_broken known breakage(s)"
msg="remaining $(($test_count-$test_broken)) test(s)"
else
msg="$test_count test(s)"
--
1.7.12.1.396.g53b3ea9
^ permalink raw reply related
* [PATCH v6 4/7] tests: change info messages from yellow/brown to bold cyan
From: Adam Spiers @ 2012-12-16 18:28 UTC (permalink / raw)
To: git list
In-Reply-To: <1355682495-22382-1-git-send-email-git@adamspiers.org>
Now that we've adopted a "traffic lights" coloring scheme, yellow is
used for warning messages, so we need to re-color info messages to
something less alarmist. Blue is a universal color for informational
messages; however we are using that for skipped tests in order to
align with the color schemes of other test suites. Therefore we use
bold cyan which is also blue-ish, but visually distinct from bold
blue. This was suggested on the list a while ago and no-one raised
any objections:
http://thread.gmane.org/gmane.comp.version-control.git/205675/focus=205966
Signed-off-by: Adam Spiers <git@adamspiers.org>
---
t/test-lib.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 220b172..5d9d0fc 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -218,7 +218,7 @@ then
pass)
tput setaf 2;; # green
info)
- tput setaf 3;; # brown
+ tput bold; tput setaf 6;; # bold cyan
*)
test -n "$quiet" && return;;
esac
--
1.7.12.1.396.g53b3ea9
^ permalink raw reply related
* [PATCH v6 5/7] tests: refactor mechanics of testing in a sub test-lib
From: Adam Spiers @ 2012-12-16 18:28 UTC (permalink / raw)
To: git list
In-Reply-To: <1355682495-22382-1-git-send-email-git@adamspiers.org>
This will allow us to test the test framework more thoroughly
without disrupting the top-level test metrics.
Signed-off-by: Adam Spiers <git@adamspiers.org>
---
t/t0000-basic.sh | 85 ++++++++++++++++++++++++++------------------------------
1 file changed, 40 insertions(+), 45 deletions(-)
diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh
index 46ccda3..fc5200f 100755
--- a/t/t0000-basic.sh
+++ b/t/t0000-basic.sh
@@ -45,39 +45,53 @@ test_expect_failure 'pretend we have a known breakage' '
false
'
-test_expect_success 'pretend we have fixed a known breakage (run in sub test-lib)' "
- mkdir passing-todo &&
- (cd passing-todo &&
- cat >passing-todo.sh <<-EOF &&
- #!$SHELL_PATH
-
- test_description='A passing TODO test
-
- This is run in a sub test-lib so that we do not get incorrect
- passing metrics
- '
-
- # Point to the t/test-lib.sh, which isn't in ../ as usual
- TEST_DIRECTORY=\"$TEST_DIRECTORY\"
- . \"\$TEST_DIRECTORY\"/test-lib.sh
+run_sub_test_lib_test () {
+ name="$1" descr="$2" # stdin is the body of the test code
+ mkdir $name &&
+ (
+ cd $name &&
+ cat >$name.sh <<-EOF &&
+ #!$SHELL_PATH
+
+ test_description='$descr (run in sub test-lib)
+
+ This is run in a sub test-lib so that we do not get incorrect
+ passing metrics
+ '
+
+ # Point to the t/test-lib.sh, which isn't in ../ as usual
+ . "\$TEST_DIRECTORY"/test-lib.sh
+ EOF
+ cat >>$name.sh &&
+ chmod +x $name.sh &&
+ export TEST_DIRECTORY &&
+ ./$name.sh >out 2>err
+ )
+}
- test_expect_failure 'pretend we have fixed a known breakage' '
- :
- '
+check_sub_test_lib_test () {
+ name="$1" # stdin is the expected output from the test
+ (
+ cd $name &&
+ ! test -s err &&
+ sed -e 's/^> //' -e 's/Z$//' >expect &&
+ test_cmp expect out
+ )
+}
+test_expect_success 'pretend we have fixed a known breakage' "
+ run_sub_test_lib_test passing-todo 'A passing TODO test' <<-\\EOF &&
+ test_expect_failure 'pretend we have fixed a known breakage' 'true'
test_done
EOF
- chmod +x passing-todo.sh &&
- ./passing-todo.sh >out 2>err &&
- ! test -s err &&
- sed -e 's/^> //' >expect <<-\\EOF &&
+ check_sub_test_lib_test passing-todo <<-\\EOF
> ok 1 - pretend we have fixed a known breakage # TODO known breakage
> # fixed 1 known breakage(s)
> # passed all 1 test(s)
> 1..1
EOF
- test_cmp expect out)
"
+
test_set_prereq HAVEIT
haveit=no
test_expect_success HAVEIT 'test runs if prerequisite is satisfied' '
@@ -159,19 +173,8 @@ then
fi
test_expect_success 'tests clean up even on failures' "
- mkdir failing-cleanup &&
- (
- cd failing-cleanup &&
-
- cat >failing-cleanup.sh <<-EOF &&
- #!$SHELL_PATH
-
- test_description='Failing tests with cleanup commands'
-
- # Point to the t/test-lib.sh, which isn't in ../ as usual
- TEST_DIRECTORY=\"$TEST_DIRECTORY\"
- . \"\$TEST_DIRECTORY\"/test-lib.sh
-
+ test_must_fail run_sub_test_lib_test \
+ failing-cleanup 'Failing tests with cleanup commands' <<-\\EOF &&
test_expect_success 'tests clean up even after a failure' '
touch clean-after-failure &&
test_when_finished rm clean-after-failure &&
@@ -181,14 +184,8 @@ test_expect_success 'tests clean up even on failures' "
test_when_finished \"(exit 2)\"
'
test_done
-
EOF
-
- chmod +x failing-cleanup.sh &&
- test_must_fail ./failing-cleanup.sh >out 2>err &&
- ! test -s err &&
- ! test -f \"trash directory.failing-cleanup/clean-after-failure\" &&
- sed -e 's/Z$//' -e 's/^> //' >expect <<-\\EOF &&
+ check_sub_test_lib_test failing-cleanup <<-\\EOF
> not ok 1 - tests clean up even after a failure
> # Z
> # touch clean-after-failure &&
@@ -202,8 +199,6 @@ test_expect_success 'tests clean up even on failures' "
> # failed 2 among 2 test(s)
> 1..2
EOF
- test_cmp expect out
- )
"
################################################################
--
1.7.12.1.396.g53b3ea9
^ permalink raw reply related
* Prebuilt man pages on Google code
From: John Keeping @ 2012-12-16 16:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
While investigating Asciidoc's quoting in this thread [1], I noticed
that my system man pages don't display Asciidoc double quoted text
correctly.
[1] http://article.gmane.org/gmane.comp.version-control.git/211533
For example in git-fast-import(1):
Here <name> is the person’s display name (for example `Com M Itter'')
and `<email> is the person’s email address (`cm@example.com''). `LT
and GT are the literal less-than (\x3c) and greater-than (\x3e)
symbols.
It turns out that Gentoo installs the man pages from git-core on Google
code, and the error can be seen in the "source" there [2].
[2] http://code.google.com/p/git-manpages/source/browse/man1/git-fast-import.1#379
When I generate man pages here, I get paired quotes (\u201C and \u201D):
Here <name> is the person’s display name (for example “Com M Itter”)
and <email> is the person’s email address (“cm@example.com”). LT and
GT are the literal less-than (\x3c) and greater-than (\x3e) symbol
I can't see any configuration option that could cause this difference,
so I assume it must be caused by some particular tool version on the
machine used to generate these man pages.
If the output is a side-effect of avoiding non-ASCII characters, is is
useful to do something like this (with appropriate Makefile support)?
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
index 1273a85..6655ec7 100644
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -89,6 +89,16 @@ template::[header-declarations]
endif::backend-docbook[]
endif::doctype-manpage[]
+ifdef::doctype-manpage[]
+ifdef::git-asciidoc-man-ascii[]
+[attributes]
+lsquo='
+rsquo='
+ldquo="
+rdquo="
+endif::git-asciidoc-man-ascii[]
+endif::doctype-manpage[]
+
ifdef::backend-xhtml11[]
[attributes]
git-relative-html-prefix=
^ permalink raw reply related
* [PATCH v2] Documentation: don't link to example mail addresses
From: John Keeping @ 2012-12-16 14:00 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20121216120405.GA14320@sigill.intra.peff.net>
Email addresses in documentation are converted into mailto: hyperlinks
in the HTML output and footnotes in man pages. This isn't desirable for
cases where the address is used as an example and is not valid.
Particularly annoying is the example "jane@laptop.(none)" which appears
in git-shortlog(1) as "jane@laptop[1].(none)", with note 1 saying:
1. jane@laptop
mailto:jane@laptop
Fix this by escaping these email addresses with a leading backslash, to
prevent Asciidoc expanding them as inline macros.
In the case of mailmap.txt, render the address monospaced so that it
matches the block examples surrounding that paragraph.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: John Keeping <john@keeping.me.uk>
---
On Sun, Dec 16, 2012 at 07:04:05AM -0500, Jeff King wrote:
> Furthermore, the right way to suppress
> expansion of macros is with a backslash escape.
[snipped an example]
> I think it's a little less ugly
> than the "$$" quoting, but not by much. No clue if one is accepted by
> more asciidoc versions or not.
>From a quick reading of the Asciidoc changelog, I think backslash
escaping should be supported just as well as "$$" quoting, which leaves
the minimal patch looking like this.
Documentation/git-fast-import.txt | 2 +-
Documentation/git-tag.txt | 2 +-
Documentation/mailmap.txt | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index d1844ea..68bca1a 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -427,7 +427,7 @@ they made it.
Here `<name>` is the person's display name (for example
``Com M Itter'') and `<email>` is the person's email address
-(``cm@example.com''). `LT` and `GT` are the literal less-than (\x3c)
+(``\cm@example.com''). `LT` and `GT` are the literal less-than (\x3c)
and greater-than (\x3e) symbols. These are required to delimit
the email address from the other fields in the line. Note that
`<name>` and `<email>` are free-form and may contain any sequence
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 247534e..2f1c0c3 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -129,7 +129,7 @@ This option is only applicable when listing tags without annotation lines.
CONFIGURATION
-------------
By default, 'git tag' in sign-with-default mode (-s) will use your
-committer identity (of the form "Your Name <your@email.address>") to
+committer identity (of the form "Your Name <\your@email.address>") to
find a key. If you want to use a different default key, you can specify
it in the repository configuration as follows:
diff --git a/Documentation/mailmap.txt b/Documentation/mailmap.txt
index 288f04e..dd89fca 100644
--- a/Documentation/mailmap.txt
+++ b/Documentation/mailmap.txt
@@ -46,7 +46,7 @@ Jane Doe <jane@desktop.(none)>
Joe R. Developer <joe@example.com>
------------
-Note how there is no need for an entry for <jane@laptop.(none)>, because the
+Note how there is no need for an entry for `<jane@laptop.(none)>`, because the
real name of that author is already correct.
Example 2: Your repository contains commits from the following
--
1.8.0.2
^ permalink raw reply related
* [PATCH] Move api-command.txt to the end of API list in api-index.txt
From: Thomas Ackermann @ 2012-12-16 12:23 UTC (permalink / raw)
To: th.acker, git
In-Reply-To: <1582223824.296627.1355560147565.JavaMail.ngmail@webmail08.arcor-online.net>
- because it describes a different form of API than the other api-* documents
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
---
Documentation/technical/api-index.sh | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/technical/api-index.sh b/Documentation/technical/api-index.sh
index 9c3f413..c2c68ed 100755
--- a/Documentation/technical/api-index.sh
+++ b/Documentation/technical/api-index.sh
@@ -10,12 +10,16 @@
while read filename
do
case "$filename" in
- api-index-skel.txt | api-index.txt) continue ;;
+ api-index-skel.txt | api-index.txt | api-command.txt) continue ;;
esac
title=$(sed -e 1q "$filename")
html=${filename%.txt}.html
echo "* link:$html[$title]"
done
+ filename=api-command.txt
+ title=$(sed -e 1q "$filename")
+ html=${filename%.txt}.html
+ echo "* link:$html[$title]"
echo "$c"
sed -n -e '/^\/\/ table of contents end/,$p' "$skel"
) >api-index.txt+
--
1.8.0.msysgit.0
---
Thomas
^ permalink raw reply related
* Re: [PATCH] Documentation: don't link to example mail addresses
From: Jeff King @ 2012-12-16 12:04 UTC (permalink / raw)
To: John Keeping; +Cc: git, Junio C Hamano
In-Reply-To: <20121215182408.GD2725@river.lan>
On Sat, Dec 15, 2012 at 06:24:09PM +0000, John Keeping wrote:
> > I think I'd just render them monospace everywhere. We are very
> > inconsistent about which form of quotes we use in the documentation (I
> > think because most of the developers read the source directly and not
> > the rendered asciidoc). And then we don't have to worry about the "$$"
> > construct (and IMHO it makes the source much more readable, and marking
> > the address as a literal looks good in the output, too).
>
> I agree that the source is more readable as monospaced, but I think we
> need to keep the quotes around the text in git-tag(1) and probably
> git-fast-import(1) so that it is differentiated from the surrounding
> text in the man page output.
Hmm, good point. I use MAN_BOLD_LITERAL, which serves that purpose, but
I guess not everyone does (and it is not the default; I wonder if it
should be). But if MAN_BOLD_LITERAL is not in use, then `` literals
have zero typographical impact in the manpages.
So maybe we do need to do something else. I was just hoping we could get
away with something more readable in the source.
By my reading of the asciidoc user guide, the mechanism that is hurting
us is that mailto is an inline macro, and that foo@bar automatically
triggers that inline macro. Furthermore, the right way to suppress
expansion of macros is with a backslash escape. Doing this:
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index d1844ea..68bca1a 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -427,7 +427,7 @@ Here `<name>` is the person's display name (for example
Here `<name>` is the person's display name (for example
``Com M Itter'') and `<email>` is the person's email address
-(``cm@example.com''). `LT` and `GT` are the literal less-than (\x3c)
+(``\cm@example.com''). `LT` and `GT` are the literal less-than (\x3c)
and greater-than (\x3e) symbols. These are required to delimit
the email address from the other fields in the line. Note that
`<name>` and `<email>` are free-form and may contain any sequence
seems to produce the output we want. I think it's a little less ugly
than the "$$" quoting, but not by much. No clue if one is accepted by
more asciidoc versions or not.
-Peff
^ permalink raw reply related
* Re: [PATCH v4 3/4] cache-tree: fix writing cache-tree when CE_REMOVE is present
From: Junio C Hamano @ 2012-12-16 10:38 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <CACsJy8DgwQ2jn=tPpE8f22JNE1Vih86d=Xf1iGBznLcwMukd+w@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>On Sun, Dec 16, 2012 at 2:20 PM, Junio C Hamano <gitster@pobox.com>
>wrote:
>> Nicely explained. I wonder if we can also add a piece of test to
>> the patch 4/4 to demonstrate the issue with CE_REMOVE entries,
>> though.
>
>A hand crafted one, maybe. I did not attempt to recreate it with git
>commands (and I don't think we update cache-tree after unpack_trees).
Yeah, that's what I thought. No need to bother creating a bug that won't appear in the real life :-)
Tusks for sanity checking.
--
Pardon terseness, typo and HTML from a tablet.
^ permalink raw reply
* Re: [PATCH v4 3/4] cache-tree: fix writing cache-tree when CE_REMOVE is present
From: Nguyen Thai Ngoc Duy @ 2012-12-16 10:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk3siqx8b.fsf@alter.siamese.dyndns.org>
On Sun, Dec 16, 2012 at 2:20 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> entry_count is used in update_one() for two purposes:
>>
>> 1. to skip through the number of processed entries in in-memory index
>> 2. to record the number of entries this cache-tree covers on disk
>>
>> Unfortunately when CE_REMOVE is present these numbers are not the same
>> because CE_REMOVE entries are automatically removed before writing to
>> disk but entry_count is not adjusted and still counts CE_REMOVE
>> entries.
>
> Nicely explained. I wonder if we can also add a piece of test to
> the patch 4/4 to demonstrate the issue with CE_REMOVE entries,
> though.
A hand crafted one, maybe. I did not attempt to recreate it with git
commands (and I don't think we update cache-tree after unpack_trees).
So I wrote something like this instead:
int main(int ac, char **av)
{
unsigned char sha1[20];
setup_git_directory();
read_cache();
active_cache[1]->ce_flags |= CE_REMOVE;
write_cache_as_tree(sha1, 0, NULL);
return 0;
}
I can polish it a bit and write new tests based on it and
test-dump-cache-tree if you want.
--
Duy
^ permalink raw reply
* Re: [PATCH] Remove misleading date form api-index-skel.txt
From: Andreas Schwab @ 2012-12-16 8:47 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: git
In-Reply-To: <38388978.118261.1355647369577.JavaMail.ngmail@webmail21.arcor-online.net>
s/form/from/
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox