t7610: use "file:///dev/null", not "/dev/null", fixes MinGW

Commit Message

Ævar Arnfjörð Bjarmason Nov. 15, 2022, 11:40 p.m. UTC

On MinGW the "/dev/null" is translated to "nul" on command-lines, even
though as in this case it'll never end up referring to an actual file.

So on Windows the fix for the previous "example.com" timeout issue in
8354cf752ec (t7610: fix flaky timeout issue, don't clone from
example.com, 2022-11-05) would yield:

  fatal: repo URL: 'nul' must be absolute or begin with ./|../

Let's evade this yet again by prefixing this with "file://", which
makes this pass in the Windows CI.

Signed-off-by: Ævar Arnfjörð Bjarmason <[e-mail]>
---

On Tue, Nov 15 2022, Taylor Blau wrote:

> On Wed, Nov 09, 2022 at 09:17:25PM -0500, Taylor Blau wrote:
>> On Thu, Nov 10, 2022 at 12:55:30AM +0100, Ævar Arnfjörð Bjarmason wrote:
>> > But we generally just fail some or all of 3..9 pretty fast, and don't
>> > start taking 20 minutes to run the test, when it took 10s before (or
>> > whatever).
>>
>> OK. I still think that in principle this is indistinguishable from not
>> running a setup test to completion.
>>
>> *But*: I'm willing to treat them differently since instead of
>> manifesting in an immediate failure later on in the suite, we hang for a
>> substantial period of time.
>>
>> So I'm content to merge this down, but I don't think it's worth
>> searching out for more of these in the future.
>
> Having merged this down to 'next', it looks like there is some CI
> fallout on the Windows tests, see:
>
>   https://github.com/ttaylorr/git/actions/runs/3473324797/jobs/5805324776
>
> I am not sure how I might have caught this earlier not having a Windows
> machine myself. Regardless, let's make sure that it is fixed up before
> this graduates.

Sorry again :( I think my CI was quite queued up at the time, and I
figured surely *this* won't have any porability issues, but forgot
about MinGW's sneaky /dev/null string-replacement behavior.

Windows CI passes with this:
https://github.com/avar/git/actions/runs/3473817195

 t/t7610-mergetool.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comments

Taylor Blau Nov. 16, 2022, 1:07 a.m. UTC | #1

On Wed, Nov 16, 2022 at 12:40:14AM +0100, Ævar Arnfjörð Bjarmason wrote:
> On MinGW the "/dev/null" is translated to "nul" on command-lines, even
> though as in this case it'll never end up referring to an actual file.
>
> So on Windows the fix for the previous "example.com" timeout issue in
> 8354cf752ec (t7610: fix flaky timeout issue, don't clone from
> example.com, 2022-11-05) would yield:
>
>   fatal: repo URL: 'nul' must be absolute or begin with ./|../
>
> Let's evade this yet again by prefixing this with "file://", which
> makes this pass in the Windows CI.

Thanks very much. I just picked this up on top of my 'ab/t7610-timeout'
branch and pushed it out to ttaylorr/git to double-check your results
against CI. (Not that I don't trust you, of course, but I'm feeling like
I should be extra-cautious ;-)).

Assuming that all looks good, then I'll push out a new version of 'next'
and dependent branches to the usual spots so that we can get 'next' back
to green.

Thanks for working on this so quickly.

Thanks,
Taylor

Ævar Arnfjörð Bjarmason Nov. 17, 2022, 10:08 a.m. UTC | #2

On Tue, Nov 15 2022, Taylor Blau wrote:

> On Wed, Nov 16, 2022 at 12:40:14AM +0100, Ævar Arnfjörð Bjarmason wrote:
>> On MinGW the "/dev/null" is translated to "nul" on command-lines, even
>> though as in this case it'll never end up referring to an actual file.
>>
>> So on Windows the fix for the previous "example.com" timeout issue in
>> 8354cf752ec (t7610: fix flaky timeout issue, don't clone from
>> example.com, 2022-11-05) would yield:
>>
>>   fatal: repo URL: 'nul' must be absolute or begin with ./|../
>>
>> Let's evade this yet again by prefixing this with "file://", which
>> makes this pass in the Windows CI.
>
> Thanks very much. I just picked this up on top of my 'ab/t7610-timeout'
> branch and pushed it out to ttaylorr/git to double-check your results
> against CI. (Not that I don't trust you, of course, but I'm feeling like
> I should be extra-cautious ;-)).
>
> Assuming that all looks good, then I'll push out a new version of 'next'
> and dependent branches to the usual spots so that we can get 'next' back
> to green.
>
> Thanks for working on this so quickly.

And thank for picking it up! Looks like "next" is passing CI now:
https://github.com/git/git/actions/runs/3475751137/jobs/5810308794

Taylor Blau Nov. 17, 2022, 9:50 p.m. UTC | #3

On Thu, Nov 17, 2022 at 11:08:08AM +0100, Ævar Arnfjörð Bjarmason wrote:
> And thank for picking it up! Looks like "next" is passing CI now:
> https://github.com/git/git/actions/runs/3475751137/jobs/5810308794

No problem. I dislike pushing out 'next' without a corresponding WC
report, but I dislike 'next' failing CI even more. So I felt like here
it was OK.

Thanks,
Taylor

Patch

diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh
index b1ba0d9a088..7b957022f1a 100755
--- a/t/t7610-mergetool.sh
+++ b/t/t7610-mergetool.sh
@@ -33,7 +33,7 @@  test_expect_success 'setup' '
 		git add foo &&
 		git commit -m "Add foo"
 	) &&
-	git submodule add /dev/null submod &&
+	git submodule add file:///dev/null submod &&
 	git add file1 "spaced name" file1[1-4] subdir/file3 .gitmodules submod &&
 	git commit -m "add initial versions" &&
 
@@ -614,7 +614,7 @@  test_expect_success 'submodule in subdirectory' '
 		)
 	) &&
 	test_when_finished "rm -rf subdir/subdir_module" &&
-	git submodule add /dev/null subdir/subdir_module &&
+	git submodule add file:///dev/null subdir/subdir_module &&
 	git add subdir/subdir_module &&
 	git commit -m "add submodule in subdirectory" &&