From: Jacob Keller <jacob.e.keller@intel.com>
To: Glen Choo <chooglen@google.com>, Junio C Hamano <gitster@pobox.com>
Cc: <git@vger.kernel.org>, Jacob Keller <jacob.keller@gmail.com>
Subject: Re: [PATCH] blame: use different author name for fake commit generated by --contents
Date: Mon, 24 Apr 2023 11:37:20 -0700 [thread overview]
Message-ID: <90f8499b-891f-ec32-096c-9ae532ef65c2@intel.com> (raw)
In-Reply-To: <kl6l354p9n52.fsf@chooglen-macbookpro.roam.corp.google.com>
On 4/24/2023 10:59 AM, Glen Choo wrote:
> Jacob Keller <jacob.e.keller@intel.com> writes:
>
>>> diff --git c/t/annotate-tests.sh w/t/annotate-tests.sh
>>> index 859693949b..4238ce45f8 100644
>>> --- c/t/annotate-tests.sh
>>> +++ w/t/annotate-tests.sh
>>> @@ -74,8 +74,8 @@ test_expect_success 'blame 1 author' '
>>>
>>> test_expect_success 'blame working copy' '
>>> test_when_finished "git restore file" &&
>>> - echo "1A quick brown fox jumps over" >file &&
>>> - echo "another lazy dog" >> file &&
>>> + echo "11A quick brown fox jumps over the" >file &&
>>> + echo "lazy dog" >>file &&
>>
>> I think the right fix for this test is to keep the first line (1A) the
>> same, and include the missing "the" I had removed before, and keep the
>> 2nd line as the changed line with "another lazy dog".
>
> This sounds right to me; it's easier to read when the working copy test
> and the --contents test use the same data
Yep, will have it this way in v2.
>>
>>> not ok 46 - passing hostname resolution information works
>>> #
>>> # BOGUS_HOST=gitbogusexamplehost.invalid &&
>>> # BOGUS_HTTPD_URL=$HTTPD_PROTO://$BOGUS_HOST:$LIB_HTTPD_PORT &&
>>> # test_must_fail git ls-remote "$BOGUS_HTTPD_URL/smart/repo.git" >/dev/null &&
>>> # git -c "http.curloptResolve=$BOGUS_HOST:$LIB_HTTPD_PORT:127.0.0.1" ls-remote "$BOGUS_HTTPD_URL/smart/repo.git" >/dev/null
>>> #
>>
>> I had thought this was the only failure, and that it has something to do
>> with my system configuration (possibly proxy settings) which affect
>> this.. I checked the firewall configuration and it doesn't appear to be
>> that...
>>
>> It would be nice to figure out what makes it so the tests fail so that I
>> can make sure tests properly pass on my submissions before sending them
>> in the future.
>
> I remember seeing a similar, flaky failure on an older version of master
> (~2-3 months ago). But if you based this on a recent version, I'm afraid
> I haven't seen this :/
I'm running on 667fcf4e1537 ("The tenth batch", 2023-04-17) and the
failure is consistent.
I'm not familiar with the curlopt stuff but it does seem like some sort
of environment failure..
When running with -x and -v:
> ++ git -c http.curloptResolve=gitbogusexamplehost.invalid:5551:127.0.0.1 ls-remote http://gitbogusexamplehost.invalid:5551/smart/repo.git
> fatal: unable to access 'http://gitbogusexamplehost.invalid:5551/smart/repo.git/': The requested URL returned error: 503
> error: last command exited with $?=128
It looks like this is a straight wrapper around CURLOPT_RESOLVE. It
looks like the HTTPD server starts just fine but perhaps some firewall
configuration is blocking connections.
I found I can skip the tests by setting GIT_TEST_HTTPD=no so thats a
decent workaround for me for now.
Thanks,
Jake
next prev parent reply other threads:[~2023-04-24 18:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-21 22:30 [PATCH] blame: use different author name for fake commit generated by --contents Jacob Keller
2023-04-21 23:34 ` Junio C Hamano
2023-04-22 0:11 ` Jacob Keller
2023-04-24 16:05 ` Junio C Hamano
2023-04-24 17:59 ` Glen Choo
2023-04-24 18:37 ` Jacob Keller [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-04-24 19:35 Jacob Keller
2023-04-24 19:36 ` Jacob Keller
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=90f8499b-891f-ec32-096c-9ae532ef65c2@intel.com \
--to=jacob.e.keller@intel.com \
--cc=chooglen@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jacob.keller@gmail.com \
/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.
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).