Re: [PATCH] blame: use different author name for fake commit generated by --contents

From: Glen Choo <chooglen@google.com>
To: Jacob Keller <jacob.e.keller@intel.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 10:59:53 -0700	[thread overview]
Message-ID: <kl6l354p9n52.fsf@chooglen-macbookpro.roam.corp.google.com> (raw)
In-Reply-To: <019057ab-c917-80cd-063b-4871e47dc382@intel.com>

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
>
>> 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 :/