On 10/23/2019 1:00 PM, Torsten Bögershausen wrote:
> On Fri, Oct 11, 2019 at 09:33:11AM -0400, Derrick Stolee wrote:
>> Here is today's test coverage report. The usual report format is
>> available online [1], [2]. The report listed below is a new format
>> that group
On Fri, Oct 11, 2019 at 09:33:11AM -0400, Derrick Stolee wrote:
> Here is today's test coverage report. The usual report format is
> available online [1], [2]. The report listed below is a new format
> that groups lines by the commit that introduced them [3]. Thanks
> Peff for the
Jeff King writes:
> But here's where it gets tricky. In addition to catching any size
> mismatches, this will also catch signedness problems. I.e., if we make
> OPT_INTEGER() use "intp", then everybody passing in &unsigned_var now
> gets a compiler warning. Which maybe is a good thing, I dunno.
From: Johannes Schindelin
In dcb500dc16c (cherry-pick/revert: advise using --skip, 2019-07-02),
`git commit` learned to suggest to run `git cherry-pick --skip` when
trying to cherry-pick an empty patch, but that was never tested for.
Here is a test that verifies that a message is given to the
In the previous patches, the mechanical application of changes left some
duplicate statements in the test case which were not strictly incorrect
but were redundant and possibly misleading. Remove these duplicate
statements so that it is clear that the intent behind the tests are that
the content
In case an invocation of a Git command fails within the subshell, the
failure will be masked. Replace the subshell with a file-redirection and
a call to test_cmp.
This change was done with the following GNU sed expressions:
s/\(\s*\)test \([^ ]*\) = "$(\(git [^)]*\))"/\1echo
When wrapping a Git command in a subshell within another command, we
throw away the Git command's exit code. In case the Git command fails,
we would like to know about it rather than the failure being silent.
Extract Git commands so that their exit codes are not lost.
Instead of using `te
Although `test -f` has the same functionality as test_path_is_file(), in
the case where test_path_is_file() fails, we get much better debugging
information.
Replace `test -f` with test_path_is_file() so that future developers
will have a better experience debugging these test cases.
Also, in the
The usual convention is for test case names to be written between
single-quotes. Change all double-quoted test case names to single-quotes
except for two test case names that use variables within.
Signed-off-by: Denton Liu
---
t/t5520-pull.sh | 4 ++--
1 file changed, 2 insertions(+), 2
Like earlier patchsets, I want to implement a feature that involves
modifications to the test suite. Since that feature will probably take a
while to polish up, however, let's clean up the test suite in a separate
patchset first so it's not blocked by the feature work.
1/15 is
Improve the test style by removing leading and trailing empty lines
within test cases. Also, reformat multi-line subshells to conform to the
existing style.
Signed-off-by: Denton Liu
---
t/t5520-pull.sh | 88 +
1 file changed, 45 insertions(+), 43
From: Johannes Schindelin
Without this, you cannot use `--run=<...>` to skip that part, and a run
with `--run=0` (which is a common way to determine the test case number
corresponding to a given test case title).
Signed-off-by: Johannes Schindelin
---
t/t1400-update-ref.s
On Mon, Oct 21, 2019 at 05:51:52PM +0900, Junio C Hamano wrote:
> > - void *value;
> > + union {
> > + int *intp;
> > + const char *strp;
> > + } value;
> [...]
> The side that actually use .vale would need to change for obvious
> reasons, which may be painful, but I agre
Here is today's test coverage report. You can find it at the normal place
[1][2][3].
I set the "master@{1}" to be the maint branch, so this should cover all new
code that
is not in the previous release.
Thanks,
-Stolee
[1] https://derrickstolee.github.io/git-test-coverage/rep
Jeff King writes:
> I wondered if we could be a bit more clever with the definition of
> "struct option". Something like:
>
> diff --git a/parse-options.h b/parse-options.h
> index 38a33a087e..99c7ff466d 100644
> --- a/parse-options.h
> +++ b/parse-options.h
> @@ -126,7 +126,10 @@ struct option {
> --- a/t/README
> +++ b/t/README
> @@ -485,6 +485,13 @@ This test harness library does the following things:
> the --root option documented above, and a '.stress-' suffix
> appended by the --stress option.
>
> + - The test framework sets GIT_CONFIG_NOSY
On Mon, Oct 21, 2019 at 09:52:11AM +0900, Junio C Hamano wrote:
> I can sympathize, but I do not think it is worth inventing OPT_U64()
> or adding "int total_i" whose value is assigned to "u64 total" after
> parsing a command line arg with OPT_INTEGER() into the former.
>
> Catching a pointer who
Peter Jones writes:
> Subject: Re: [PATCH v2 1/4] libgit: Add a read-only helper to test the
> worktree lock
Having a word "worktree" somewhere on the title is good, but have it
as the "I am changing this area"; "libgit" does not give readers the
hint th
SZEDER Gábor writes:
> The reason for that bogus value is that '--total's parameter is parsed
> via parse-options's OPT_INTEGER into a uint64_t variable [1]...
>
> Change the type of that variable from uint64_t to int, to match what
> parse-options expects; in the tests of the progress output we
an. For a full build log on s390x see [1].
>>
>> Gah, my progress display fixes strike again...
>>
>> I think the patch below should fix it, but I could only test it on
>> little-endian systems. Could you please confirm that it indeed works
>> on big-endian as w
rogress display fixes strike again...
>
> I think the patch below should fix it, but I could only test it on
> little-endian systems. Could you please confirm that it indeed works
> on big-endian as well?
>
>
> --- >8 ---
>
> Subject: [PATCH] test-progress: fix
but I could only test it on
little-endian systems. Could you please confirm that it indeed works
on big-endian as well?
--- >8 ---
Subject: [PATCH] test-progress: fix test failures on big-endian systems
In 't0500-progress-display.sh' all tests running 'test-tool progress
--to
to implement a feature that involves
> modifications to the test suite. Since that feature will probably take a
> while to polish up, however, let's clean up the test suite in a separate
> patchset first so it's not blocked by the feature work.
>
> 1/15 is a cleanup to an unrel
Like earlier patchsets, I want to implement a feature that involves
modifications to the test suite. Since that feature will probably take a
while to polish up, however, let's clean up the test suite in a separate
patchset first so it's not blocked by the feature work.
1/15 is a cle
Improve the test style by removing leading and trailing empty lines
within test cases. Also, reformat multi-line subshells to conform to the
existing style.
Signed-off-by: Denton Liu
---
t/t5520-pull.sh | 88 +
1 file changed, 45 insertions(+), 43
In case an invocation of a Git command fails within the subshell, the
failure will be masked. Replace the subshell with a file-redirection and
a call to test_cmp.
This change was done with the following GNU sed expressions:
s/\(\s*\)test \([^ ]*\) = "$(\(git [^)]*\))"/\1echo
Although `test -f` has the same functionality as test_path_is_file(), in
the case where test_path_is_file() fails, we get much better debugging
information.
Replace `test -f` with test_path_is_file() so that future developers
will have a better experience debugging these test cases.
Also, in the
The usual convention is for test case names to be written between
single-quotes. Change all double-quoted test case names to single-quotes
except for two test case names that use variables within.
Signed-off-by: Denton Liu
---
t/t5520-pull.sh | 4 ++--
1 file changed, 2 insertions(+), 2
In the previous patches, the mechanical application of changes left some
duplicate statements in the test case which were not strictly incorrect
but were redundant and possibly misleading. Remove these duplicate
statements so that it is clear that the intent behind the tests are that
the content
When wrapping a Git command in a subshell within another command, we
throw away the Git command's exit code. In case the Git command fails,
we would like to know about it rather than the failure being silent.
Extract Git commands so that their exit codes are not lost.
Instead of using `te
Add the function is_worktree_locked(), which is a helper to tell if a
worktree is locked without having to be able to modify it.
Signed-off-by: Peter Jones
---
builtin/worktree.c | 2 +-
worktree.c | 16
worktree.h | 5 +
3 files changed, 22 insertions(+),
Also, fix minor wording mistake in referenced config section.
Signed-off-by: Philip Oakley
---
The basic --local config also doesn't appear to be well defined here.
test-lib.sh sets GIT_TEMPLATE_DIR="$GIT_BUILD_DIR"/templates/blt
If no config template then..? e
Doan Tran Cong Danh writes:
> If we accidentally lifted the check inside our code base, the test may
> still failed because the provided parameter is not a valid ref.
Makes sense. Another option would be to use a valid ref to make
sure there are no other possible reason for the command t
On Thu, Oct 17, 2019 at 7:35 PM Denton Liu wrote:
> Although `test -f` has the same functionality as test_path_is_file(), in
> the case where test_path_is_file() fails, we get much better debugging
> information.
>
> Replace `test -f` with test_path_is_file() so that future develop
520-pull.sh b/t/t5520-pull.sh
> @@ -622,10 +648,16 @@ test_expect_success 'pull --rebase fails on unborn
> branch with staged changes' '
> git add staged-file &&
> - test "$(git ls-files)" = staged-file &&
> +
Although `test -f` has the same functionality as test_path_is_file(), in
the case where test_path_is_file() fails, we get much better debugging
information.
Replace `test -f` with test_path_is_file() so that future developers
will have a better experience debugging these test cases. Also, in the
On Thu, Oct 17, 2019 at 7:17 PM Denton Liu wrote:
> Instead of using `test -n` or `test -z`, replace them respectively with
> invocations of test_file_not_empty() and test_must_be_empty().
>
> Signed-off-by: Denton Liu
> ---
> diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
&g
On Thu, Oct 17, 2019 at 7:17 PM Denton Liu wrote:
> Although `test -f` has the same functionality as test_path_is_file(), in
> the case where test_path_is_file() fails, we get much better debugging
> information. Replace `test -f` with test_path_is_file so that future
> developers
Like earlier patchsets, I want to implement a feature that involves
modifications to the test suite. Since that feature will probably take a
while to polish up, however, let's clean up the test suite in a separate
patchset first so it's not blocked by the feature work.
Denton Liu (12
Improve the test style by removing leading and trailing empty lines
within test cases. Also, reformat multi-line subshells to conform to the
existing style.
Signed-off-by: Denton Liu
---
t/t5520-pull.sh | 88 +
1 file changed, 45 insertions(+), 43
Although `test -f` has the same functionality as test_path_is_file(), in
the case where test_path_is_file() fails, we get much better debugging
information. Replace `test -f` with test_path_is_file so that future
developers will have a better experience debugging these test cases.
Signed-off-by
The usual convention is for test case names to be written between
single-quotes. Change all double-quoted test case names to single-quotes
except for two test case names that use variables within.
Signed-off-by: Denton Liu
---
t/t5520-pull.sh | 4 ++--
1 file changed, 2 insertions(+), 2
In case an invocation of a Git command fails within the subshell, the
failure will be masked. Replace the subshell with a file-redirection and
a call to test_cmp.
This change was done with the following GNU sed expressions:
s/\(\s*\)test \([^ ]*\) = "$(\(git [^)]*\))"/\1echo
Instead of using `test -n` or `test -z`, replace them respectively with
invocations of test_file_not_empty() and test_must_be_empty().
Signed-off-by: Denton Liu
---
t/t5520-pull.sh | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
From: Johannes Schindelin
Without this, you cannot use `--run=<...>` to skip that part, and a run
with `--run=0` (which is a common way to determine the test case number
corresponding to a given test case title).
Signed-off-by: Johannes Schindelin
---
t/t1400-update-ref.s
On Fri, Oct 11, 2019 at 09:33:11AM -0400, Derrick Stolee wrote:
> Here is today's test coverage report. The usual report format is
> available online [1], [2]. The report listed below is a new format
> that groups lines by the commit that introduced them [3]. Thanks
> Peff fo
On 16/10/2019 17:47, SZEDER Gábor wrote:
On Wed, Oct 16, 2019 at 01:45:15PM +0100, Philip Oakley wrote:
Signed-off-by: Philip Oakley
---
While tring to get to grips with some Git-for-Windows config settings
for testing >4GiB files, I couldn't find any note in the readme about
the tes
On Wed, Oct 16, 2019 at 01:45:15PM +0100, Philip Oakley wrote:
> Signed-off-by: Philip Oakley
> ---
>
> While tring to get to grips with some Git-for-Windows config settings
> for testing >4GiB files, I couldn't find any note in the readme about
> the test system confi
Signed-off-by: Philip Oakley
---
While tring to get to grips with some Git-for-Windows config settings
for testing >4GiB files, I couldn't find any note in the readme about
the test system config file sources.
Is this the right place for the information, is it complete enough,
an
From: Johannes Schindelin
Without this, you cannot use `--run=<...>` to skip that part, and a run
with `--run=0` (which is a common way to determine the test case number
corresponding to a given test case title).
Signed-off-by: Johannes Schindelin
---
t/t1400-update-ref.s
>From commit bbb1b8a35a, ("notes: check number of parameters to "git
notes copy"", 2010-06-28), we have a test for too many or too few
of parameters provided to `git notes copy'.
However, the test is only ensure the command will fail but it doesn't
really check
Hi Thomas & Junio,
On Mon, 7 Oct 2019, Thomas Gummerer wrote:
> On 10/07, Junio C Hamano wrote:
> > Johannes Schindelin writes:
> >
> > > Date: Fri, 04 Oct 2019 08:09:25 -0700 (PDT)
> > > [...]
> > > X-Google-Original-Date: Fri, 04 Oct 2019 15:09:10 GMT
> > > [...]
> > >
> > > I am fai
Here is today's test coverage report. The usual report format is
available online [1], [2]. The report listed below is a new format
that groups lines by the commit that introduced them [3]. Thanks
Peff for the feedback on that idea.
Note: the pu branch does not build due to interactions be
Johannes Schindelin writes:
> I should note that I looked through all of the hits of `git grep -w
> except -- t/` and did not find any other typo.
Thanks.
rough all of the hits of `git grep -w
except -- t/` and did not find any other typo.
Thanks,
Johannes
> + lama
> + ball
> sam
> bat
> hask
> - lama
> - ball
> EOF
> - test-tool config configset_get_value case.baz config2 .git/co
From: Tanay Abhra
Change test 'find value_list for a key from a configset' to redirect the
result to 'expect' instead of 'except' which was a typo.
With this change, the test case actually fails because it uses
`configset_get_value`. Clearly, this was intended to
: fix a test that has a typo
t/t1308-config-set.sh | 8
1 file changed, 4 insertions(+), 4 deletions(-)
base-commit: 70bf0b755af4d1e66da25b7805cac0e481a082e4
Published-As:
https://github.com/gitgitgadget/git/releases/tag/pr-387%2Fdscho%2Fconfig-set-test-fix-v1
Fetch-It-Via: git fetch
Hi Dscho,
On 10/10/2019 10:03, Johannes Schindelin wrote:
So a better interpretation would have been:
The default creation factor is 60 (roughly speaking, it wants at
most 60% of the diffs' lines to differ, otherwise it considers
them not to be a match.
This is still inaccurate, but at le
Hi Philip,
On Wed, 9 Oct 2019, Philip Oakley wrote:
> On 08/10/2019 13:46, Johannes Schindelin wrote:
> > Hi Junio,
> >
> > On Tue, 8 Oct 2019, Junio C Hamano wrote:
> >
> > > Johannes Schindelin writes:
> > >
> > > > > I didn't quite understand this part, though.
> > > > >
> > > > > The de
Hi Dscho,
On 08/10/2019 13:46, Johannes Schindelin wrote:
Hi Junio,
On Tue, 8 Oct 2019, Junio C Hamano wrote:
Johannes Schindelin writes:
I didn't quite understand this part, though.
The default creation factor is 60 (roughly speaking, it wants 60% of
the lines to match between
Hi Junio,
On Tue, 8 Oct 2019, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> I didn't quite understand this part, though.
> >>
> >> The default creation factor is 60 (roughly speaking, it wants 60% of
> >> the lines to match between two patches, otherwise it considers the
> >
On 10/5/2019 5:11 PM, brian m. carlson wrote:
> This series consists mostly of additional test fixes for SHA-256, plus
> some test framework improvements and a new option to rev-parse.
>
> Up until now, most of the test changes have been directly related to
> fixing hash values o
Johannes Schindelin writes:
>> I didn't quite understand this part, though.
>>
>> The default creation factor is 60 (roughly speaking, it wants 60% of
>> the lines to match between two patches, otherwise it considers the
>> patches to be unrelated).
>>
>> Would the updated creation fa
Hi Junio,
On Mon, 7 Oct 2019, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> I just implemented this here:
> >> https://github.com/gitgitgadget/gitgitgadget/pull/128 (it still needs to
> >> be reviewed and merged before it takes effect).
> >
> > FWIW this is now merged.
>
> Nice.
>
>
On 10/07, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Date: Fri, 04 Oct 2019 08:09:25 -0700 (PDT)
> > [...]
> > X-Google-Original-Date: Fri, 04 Oct 2019 15:09:10 GMT
> > [...]
> >
> > I am fairly certain that the latter is the actual `Date:` line sent to
> > GMail,
Johannes Schindelin writes:
>> I just implemented this here:
>> https://github.com/gitgitgadget/gitgitgadget/pull/128 (it still needs to
>> be reviewed and merged before it takes effect).
>
> FWIW this is now merged.
Nice.
I didn't quite understand this part, though.
The default creation f
Johannes Schindelin writes:
> Date: Fri, 04 Oct 2019 08:09:25 -0700 (PDT)
> [...]
> X-Google-Original-Date: Fri, 04 Oct 2019 15:09:10 GMT
> [...]
>
> I am fairly certain that the latter is the actual `Date:` line sent to
> GMail, and GMail just decides that it will not r
Hi Junio,
On Sun, 6 Oct 2019, Johannes Schindelin wrote:
> On Sun, 6 Oct 2019, Junio C Hamano wrote:
>
> > "Johannes Schindelin via GitGitGadget"
> > writes:
> >
> > > Range-diff vs v2:
> > >
> > > 1: 4d0b38125a = 1: 4d0b38125a push: do not pretend to return `int`
> > > from `die_push_simp
to
GMail, and GMail just decides that it will not respect it.
Once https://github.com/gitgitgadget/gitgitgadget/pull/125 makes it into
GitGitGadget (adding the `/preview` command that allows to send patch
series to the PR owner as a test), it should be easier to start
investigating further.
Unless anybody here knows why GMail rejects the header. Maybe it is the
`GMT`?
Ciao,
Dscho
"Johannes Schindelin via GitGitGadget"
writes:
> Changes since v2:
>
> * The overflow check introduced in v1 was consolidated into a single
>helper.
Looks good to me.
> Range-diff vs v2:
>
> 1: 4d0b38125a = 1: 4d0b38125a push: do not pretend to return `int` from
> `die_push_simple()`
This test produces pseudo-collisions and tests git diff's behavior with
them, and is therefore sensitive to the hash in use. Update the test to
compute the collisions for both SHA-1 and SHA-256 using appropriate
constants. Move the heredocs inside the setup block so that all of the
setup cod
This series consists mostly of additional test fixes for SHA-256, plus
some test framework improvements and a new option to rev-parse.
Up until now, most of the test changes have been directly related to
fixing hash values or sizes in some way. In other words, previous test
fixes would be
From: Johannes Schindelin
... because we can, now. Technically, we actually build using `MSBuild`,
which is however pretty close to building interactively in Visual
Studio.
As there is no convenient way to run Git's test suite in Visual Studio,
we unpack a Portable Git to run it, using the
ne: the project files
are generated, MSBuild (which is kind of the command-line equivalent of
Visual Studio's "Build" operation) is used to build Git, and then a
parallelized test job runs the test suite in a Portable Git.
These patches are based on js/visual-studio.
Changes since v2:
From: Johannes Schindelin
Git for Windows jumps through hoops to provide a development environment
that allows to build Git and to run its test suite. To that end, an
entire MSYS2 system, including GNU make and GCC is offered as "the Git
for Windows SDK". It does come at a price:
Before, the expect files of the test case were being generated in the
setup method. However, it would make more sense to generate these files
within the test cases that actually use them so that it's obvious to
future readers where the expected values are coming from.
Move the generation o
---
t/test-lib-functions.sh | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 87bf3a2287..b299ecc326 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -228,9 +228,11 @@ test_commit () {
# can be a
The test was originally designed for the case where user reported that
setting GIT_SSH to a .bat file with spaces in path fails on Windows:
https://github.com/git-for-windows/git/issues/692
The test has two different problems:
1. It succeeds with AND without fix eb7c7863 that addressed user&#
From: Alexandr Miloslavskiy
The test was originally designed for the case where user reported
that setting GIT_SSH to a .bat file with spaces in path fails on
Windows: https://github.com/git-for-windows/git/issues/692
The test has two different problems:
1. It succeeds with AND without fix
From: Johannes Schindelin
... because we can, now. Technically, we actually build using `MSBuild`,
which is however pretty close to building interactively in Visual
Studio.
As there is no convenient way to run Git's test suite in Visual Studio,
we unpack a Portable Git to run it, using the
From: Johannes Schindelin
Git for Windows jumps through hoops to provide a development environment
that allows to build Git and to run its test suite. To that end, an
entire MSYS2 system, including GNU make and GCC is offered as "the Git
for Windows SDK". It does come at a price:
ne: the project files
are generated, MSBuild (which is kind of the command-line equivalent of
Visual Studio's "Build" operation) is used to build Git, and then a
parallelized test job runs the test suite in a Portable Git.
These patches are based on js/visual-studio.
Changes since v1:
SZEDER Gábor writes:
>> Hmm...
>>
>> > +# ,---ooo-.
>> > +# / D,R e \
>> > +# o--o-o-o---ox
>> > +# \B/
>> > +# `---ooo-'
>> > +#Ac
>>
>> What's the first parent of the merge between
From: Johannes Schindelin
Git for Windows jumps through hoops to provide a development environment
that allows to build Git and to run its test suite. To that end, an
entire MSYS2 system, including GNU make and GCC is offered as "the Git
for Windows SDK". It does come at a price:
From: Johannes Schindelin
... because we can, now. Technically, we actually build using `MSBuild`,
which is however pretty close to building interactively in Visual
Studio.
As there is no convenient way to run Git's test suite in Visual Studio,
we unpack a Portable Git to run it, using the
ne: the project files
are generated, MSBuild (which is kind of the command-line equivalent of
Visual Studio's "Build" operation) is used to build Git, and then a
parallelized test job runs the test suite in a Portable Git.
These patches are based on js/visual-studio.
Johannes Schindeli
Before, the expect files of the test case were being generated in the
setup method. However, it would make more sense to generate these files
within the test cases that actually use them so that it's obvious to
future readers where the expected values are coming from.
Move the generation o
---
t/test-lib-functions.sh | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 87bf3a2287..b299ecc326 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -228,9 +228,11 @@ test_commit () {
# can be a
From: Alexandr Miloslavskiy
According to its name, the test is designed for UTF-16-LE-BOM.
However, possibly due to copy&paste oversight, it was using UTF-32.
While the test succeeds (extra \000\000 are interpreted as NUL),
I myself had an unrelated problem which caused the test to fail.
On 24.09.2019 5:46, Torsten Bögershausen wrote:
Out of curiosity:
What made the test fail, and does it pass noe ?
It failed to a bug in Windows Debug build, which caused iconv() to fail
in most cases, see:
https://public-inbox.org/git/pull.348.git.gitgitgad...@gmail.com/
How about the
d(oid) is a small change in a
> really big commit. Here is the change:
I'd suggest not looking too closely at this one yet. This was a
preliminary split by Christian of some older code that I had written. I
think it needs to be split up more, and probably does need more test
coverage (bitm
On Mon, Sep 23, 2019 at 03:04:19AM -0700, Alexandr Miloslavskiy via
GitGitGadget wrote:
> From: Alexandr Miloslavskiy
>
> According to its name, the test is designed for UTF-16-LE-BOM.
> However, possibly due to copy&paste oversight, it was using UTF-32 file.
>
> W
On 9/19/2019 10:23 AM, Derrick Stolee wrote:
> Here is today's test coverage report.
And I took a close look at the report, looking for interesting cases
that are not covered. Most of the uncovered lines were due to simple
refactors or error conditions. I point out a few below that took
From: Alexandr Miloslavskiy
According to its name, the test is designed for UTF-16-LE-BOM.
However, possibly due to copy&paste oversight, it was using UTF-32 file.
While the test succeeds (probably interprets extra \x00\x00 as embedded
zero), I myself had an unrelated problem which caused
Commit 1/2: t0028: fix test for UTF-16-LE-BOM Commit 2/2: t0028: add more
tests Please refer to individual commit messages for more information.
Alexandr Miloslavskiy (2):
t0028: fix test for UTF-16-LE-BOM
t0028: add more tests
t/t0028-working-tree-encoding.sh | 41
From: Alexandr Miloslavskiy
According to its name, the test its designed for UTF-16-LE-BOM.
However, possibly due to copy&paste oversight, it was using UTF-32 file.
While the test succeeds (probably interprets extra \x00\x00 as embedded
zero), I myself had an unrelated problem which caused
On Fri, Sep 20, 2019 at 02:47:38PM -0700, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> > At the top of 't6120-describe.sh' an ASCII graph illustrates the
> > repository's history used in this test script. This graph is a bit
> > misleading, because it
SZEDER Gábor writes:
> At the top of 't6120-describe.sh' an ASCII graph illustrates the
> repository's history used in this test script. This graph is a bit
> misleading, because it swapped the second merge commit's first and
> second parents.
Hm
On Fri, Sep 20, 2019 at 11:14:56AM -0400, Derrick Stolee wrote:
> On 9/19/2019 5:47 PM, SZEDER Gábor wrote:
> > These conditions are not covered properly in the test suite. As far
> > as purely test coverage goes, they are all executed several times over
> > in 't6120-de
> // do stuff #1
> else
> // do stuff #2
> } else {
> // do stuff #3
> }
>
> These conditions are not covered properly in the test suite. As far
> as purely test coverage goes, they are all executed several times over
> in 't6120-describe.sh'
1 - 100 of 7144 matches
Mail list logo
