On Mon, May 15, 2017 at 10:05:29PM +0200, Johannes Sixt wrote:
> I observe the following failure on Windws with origin/next, in
> t5400-send-pack.sh
>
> +++ diff -u expect refs
> --- expect Mon May 15 06:54:59 2017
> +++ refs Mon May 15 06:54:59 2017
> @@ -1,4 +1,3 @@
> 5285e1710002a06a379056b0d21357a999f3c642 refs/heads/master
> -5285e1710002a06a379056b0d21357a999f3c642 refs/remotes/origin/HEAD
> 5285e1710002a06a379056b0d21357a999f3c642 refs/remotes/origin/master
> 53d9066ca10f2e103b33caf3a16a723553c33b00 .have
> error: last command exited with $?=1
> not ok 16 - receive-pack de-dupes .have lines
Interesting that it's the symref. I wonder if that is important (though
they should always be implemented as a real symref file and not a
symlink, so I don't think FS limitations would come into play).
For sanity, you might want to double-check that the "shared-fork"
repository has that symref on disk, and that for-each-ref reports it.
But...
> The trace file looks like this:
>
> -------- trace --------
> packet: receive-pack> 5285e1710002a06a379056b0d21357a999f3c642 refs/heads/master\0report-status delete-refs side-band-64k quiet atomic ofs-delta agent=git/2.13.0.497.g5af12421b0
> packet: receive-pack> 5285e1710002a06a379056b0d21357a999f3c642 refs/remotes/origin/HEAD
Wait, there it is in the receive-pack output. But if we look at what
"push" receives:
> packet: push< 5285e1710002a06a379056b0d21357a999f3c642 refs/heads/master\0report-status delete-refs side-band-64k quiet atomic ofs-delta agent=git/2.13.0.497.g5af12421b0
> packet: receive-pack> 5285e1710002a06a379056b0d21357a999f3c642 refs/remotes/origin/master
> packet: push< 5285e1710002a06a379056b0d21357a999f3c642 refs/remotes/origin/master
It's skipped! So either:
1. receive-pack wrote the trace line without sending it (which seems
an unlikely bug to differ between platforms)
2. push some didn't receive it (which makes no sense; this is a stream
socket and it was able to parse the next pktline)
3. push did get it but for some reason didn't write the trace (also
unlikely as with option 1)
4. There is something racy and unportable about both programs writing
to the same trace file. It's opened with O_APPEND, which means that
each write should atomically position the pointer at the end of the
file. Is it possible there's a problem with that in the way
O_APPEND works on Windows?
If that was the case, though, I'd generally expect a sheared write
or a partial overwrite. The two origin/HEAD lines from the two
programs are the exact same length, but I'd find it more likely for
the overwrite to happen with one of the follow-on lines.
So all of those sound kind of implausible. If you run the test over and
over, does it happen consistently, and is it always the same line?
-Peff