On 6/20/22 2:04 PM, rsbecker@xxxxxxxxxxxxx wrote: > Subtests t5510.69, 71, 97, 99, 125, 127, 147, 149, 151, 153, 155, 157, 159, 161, 163, 165, 167, 170 failed in rc1 on the NonStop ia64 platform. These were working in rc0, but after analysis, I do not think that is relevant. Here is what we see for subtest 69: > > expecting success of 5510.69 'link prune fetch.prune=unset remote.origin.prune=unset fetch.pruneTags=unset remote.origin.pruneTags=unset --prune origin refs/tags/*:refs/tags/*; branch:kept tag:pruned': > ... > git fetch "file:///home/jenkins/.jenkins/workspace/Git_Pipeline@2/t/trash directory.t5510-fetch/." "+refs/heads/*:refs/remotes/origin/*" && > ... > git$git_fetch_c fetch --prune "file:///home/jenkins/.jenkins/workspace/Git_Pipeline/t/trash directory.t5510-fetch/." refs/tags/*:refs/tags/* && > > What seems to be happening is that the test script is computing the wrong parent directory in the second case, cutting the @2. We use Jenkins for our builds and occasional multiple builds run. The @2 is Jenkins way of running in another place. This seems to be confusing the script parsing of the parent, causing the issue. When I rebuilt and test in the primary directory, the failures disappeared because no @2. Yes, the script is incorrectly computing the remote URL. This is not a bug in Git, but a bug in the test script. The issue is this line (some tabs removed): new_cmdline=$(printf "%s" "$cmdline" | perl -pe 's[origin(?!/)]["'"$remote_url"'"]g') At this point, $remote_url contains the file path including the @ symbol. However, this perl invocation is dropping everything starting at the @ to the next slash. I'm not sure of a better way to accomplish what is trying to be done here (replace 'origin' with that specific url) without maybe causing other issues. This line was introduced by e1790f9245f (fetch tests: fetch <url> <spec> as well as fetch [<remote>], 2018-02-09). Thanks, -Stolee
