git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Derrick Stolee <stolee@gmail.com>
To: "Torsten Bögershausen" <tboegi@web.de>
Cc: Git List <git@vger.kernel.org>, Jeff King <peff@peff.net>
Subject: Re: Git Test Coverage Report (October 11)
Date: Thu, 24 Oct 2019 13:04:04 -0400	[thread overview]
Message-ID: <b0caf237-6580-0b63-5cad-7b1ecf8a1710@gmail.com> (raw)
In-Reply-To: <20191024152508.a6vr7nh62wsqzy6u@tb-raspi4>

On 10/24/2019 11:25 AM, Torsten Bögershausen wrote:
> On Wed, Oct 23, 2019 at 02:07:20PM -0400, Derrick Stolee wrote:
>> 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 groups lines by the commit that introduced them [3]. Thanks
>>>> Peff for the feedback on that idea.
>>>>
>>>
>>> []
>>>>
>>>> Torsten Bögershausen	ebb8d2c9 mingw: support UNC in git clone file://server/share/repo
>>>> connect.c
>>>> ebb8d2c9 921) path = host - 2; /* include the leading "//" */
>>>>
>>>
>>> I actually looked into this one, and my understanding is that the code path
>>> makes only sense for windows and is only tested on Windows in t5500.
>>> (Linux/Unix/POSIX don't use UNC path names starting with "//" )
>>>
>>> How can we avoid those "not covered by test" warnings?
>>>
>>> One solution could be to use
>>>
>>> #ifndef has_dos_drive_prefix
>>> #define has_dos_drive_prefix(a) 0
>>> #endif
>>>
>>> in git-compat-util.h and hope that the compiler is smart enough
>>> to optimize away that line of code.
>>>
>>> Another way could be to have #ifdefs in connect.c, so that it
>>> is clear "this is Windows only".
>>>
>>> Or make a comment for the "cover report" saying "not covered".
>>>
>>> Are there any good or better thoughts on this ?
>>
>> One way to avoid this is to add ignored lines to the test-coverage
>> repo [1]. These only work if the exact contents match on a specific
>> line number, but can be a way to stop noise in the short-term.
>>
>> For example, I added a few lines to ignore in commit-graph.c [2],
>> but I haven't added ignored lines in a while.
>>
>> I'm happy to take a PR including the lines you want to ignore, or
>> I could take inventory of the lines in the current report before regenerating
>> a test for -rc1.
>>
>> Thanks,
>> -Stolee
>>
>> [1] https://github.com/derrickstolee/git-test-coverage
>>
>> [2] https://github.com/derrickstolee/git-test-coverage/blob/master/ignored/commit-graph.c
> 
> I added a PR as suggested.
> One thing, that came into my mind:
> 
> Would it make sense to loosen the condition:
> 921:path = host - 2; /* include the leading "//" */
> 
> Remove the line number:
> host - 2; /* include the leading "//" */
> 
> That would assume, that the line is unique within the file,
> (can be checked with unique) .
> It can give a more robust handling
> when lines are added in the file and file numbers change,
> but the content is the same.

I'll consider making the line number optional. The reason I put
the numbers there was so we could have

	994:return 1;

and that would check a particular error-check path, but not
ALL places with "return 1;".

Your line is particularly unique, so ignoring all lines with
that text should be fine.

Thanks!
-Stolee


      reply	other threads:[~2019-10-24 17:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-11 13:33 Git Test Coverage Report (October 11) Derrick Stolee
2019-10-17  6:46 ` Jeff King
2019-10-23 17:00 ` Torsten Bögershausen
2019-10-23 18:07   ` Derrick Stolee
2019-10-24 15:25     ` Torsten Bögershausen
2019-10-24 17:04       ` Derrick Stolee [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b0caf237-6580-0b63-5cad-7b1ecf8a1710@gmail.com \
    --to=stolee@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=tboegi@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).