git svn clones flawlessly on Windows, crashes silently on OS X - status of externals support?

Question

I'm trying to use git svn to clone a repository that contains externals. On my Windows7 machine it works perfectly. On my Mac it fails silently after creating the empty local repository.

The posts that speak to some of the issues surrounding this are over two years old, so I'm hoping things have changed.

I've tried with the versions of Git and SVN installed with XCode, and with newer versions installed with HomeBrew and MacPorts. The latest version of Git (2.7.2) is the one I've done my troubleshooting with.

I found the threads that speak of needing to link the SVN Perl modules into directories being searched by the Perl runtime, and have done something comparable with these:

sudo ln -s /opt/local/lib/perl5/vendor_perl/5.22/darwin-thread-multi-2level/SVN /opt/local/lib/perl5/site_perl/5.22/darwin-thread-multi-2level/SVN
sudo ln -s /opt/local/lib/perl5/vendor_perl/5.22/darwin-thread-multi-2level/auto /opt/local/lib/perl5/site_perl/5.22/auto

If I try with Git's debugger turned on, like so:

GIT_TRACE=1 git svn clone -s https://my-remote-repo

I get a bunch of redundant messages that look similar to the below, with something suspicious happening right at the time Git encounters its first external reference:

...
Checked through r45000
16:49:19.677091 git.c:348 trace: built-in: git 'config' 'svn-remote.svn.branches-maxRev' '45000'
16:49:19.684111 git.c:348 trace: built-in: git 'config' 'svn-remote.svn.tags-maxRev' '45000' 
Checked through r45100
16:49:19.721522 git.c:348 trace: built-in: git 'config' 'svn-remote.svn.branches-maxRev' '45100' 
16:49:19.728460 git.c:348 trace: built-in: git 'config' 'svn-remote.svn.tags-maxRev' '45100'
16:49:19.784923 git.c:348 trace: built-in: git 'config' 'svn-remote.svn.reposRoot' 'https://a-remote-external' 
16:49:19.807647 git.c:348 trace: built-in: git 'config' 'svn-remote.svn.branches-maxRev' '45172' 
16:49:19.814647 git.c:348 trace: built-in: git 'config' 'svn-remote.svn.tags-maxRev' '45172'

If I run with the Perl debugger like so:

PERLDB_OPTS="NonStop frame=5" /opt/local/bin/perl5.22 -d $(git --exec-path)/git-svn clone -s https://my-remote-repository

I get the following stacktrace mush right before it crashes. It looks like multiple processes are sending output to TTY so the stacktraces are interleaved. There is a reference to Error::throw() down at the bottom that I hope will be helpful.

  in  .=main::post_fetch_checkout() from /opt/local/libexec/git-core/git-svn:387
   in  $=main::verify_ref('HEAD^0') from /opt/local/libexec/git-core/git-svn:1716
    in  $=Git::command_oneline(ref(ARRAY), ref(HASH)) from /opt/local/libexec/git-core/git-svn:1806
     in  @=Git::command_output_pipe(ref(ARRAY), ref(HASH)) from /opt/local/lib/perl5/site_perl/5.22/Git.pm:314
      in  @=Git::_command_common_pipe('-|', ref(ARRAY), ref(HASH)) from /opt/local/lib/perl5/site_perl/5.22/Git.pm:344
       in  @=Git::_maybe_self(ref(ARRAY), ref(HASH)) from /opt/local/lib/perl5/site_perl/5.22/Git.pm:1561
        in  $=UNIVERSAL::isa(ref(ARRAY), 'Git') from /opt/local/lib/perl5/site_perl/5.22/Git.pm:1549
       in  .=Git::_check_valid_cmd('rev-parse') from /opt/local/lib/perl5/site_perl/5.22/Git.pm:1569
from /opt/local/lib/perl5/site_perl/5.22/Git.pm:1598
        in  .=Git::_setup_git_cmd_env(undef) from /opt/local/lib/perl5/site_perl/5.22/Git.pm:1608
        in  .=Git::_execv_git_cmd('rev-parse', '--verify', 'HEAD^0') from /opt/local/lib/perl5/site_perl/5.22/Git.pm:1609
     in  @=Error::subs::with(ref(CODE)) from /opt/local/lib/perl5/site_perl/5.22/Git.pm:325
     in  $=Error::catch('Git::Error::Command', ref(CODE)) from /opt/local/lib/perl5/site_perl/5.22/Git.pm:325
     in  .=Error::subs::try(ref(CODE), ref(HASH)) from /opt/local/lib/perl5/site_perl/5.22/Git.pm:325
      in  .=CODE(0x7fa8a367bd40)() from /opt/local/lib/perl5/vendor_perl/5.22/Error.pm:421
       in  .=Git::_cmd_close('rev-parse --verify HEAD^0', ref(GLOB)) from /opt/local/lib/perl5/site_perl/5.22/Git.pm:319
        in  .=Error::throw('Git::Error::Command', 'rev-parse --verify HEAD^0', 128) from /opt/local/lib/perl5/site_perl/5.22/Git.pm:1640
         in  $=Git::Error::Command::new('Git::Error::Command', 'rev-parse --verify HEAD^0', 128) from /opt/local/lib/perl5/vendor_perl/5.22/Error.pm:184
          in  $=Error::new('Git::Error::Command', '-text', 'command returned error', '-cmdline', 'rev-parse --verify HEAD^0', '-value', 128, '-outputref', undef) from /opt/local/lib/perl5/site_perl/5.22/Git.pm:1466
      in  $=CODE(0x7fa8a31d3db8)(ref(Git::Error::Command), undef, '') from /opt/local/lib/perl5/vendor_perl/5.22/Error.pm:426
      in  $=Error::subs::run_clauses(ref(HASH), ref(Git::Error::Command), undef, ref(ARRAY)) from /opt/local/lib/perl5/vendor_perl/5.22/Error.pm:432
       in  $=Scalar::Util::blessed(ref(Git::Error::Command)) from /opt/local/lib/perl5/vendor_perl/5.22/Error.pm:324
       in  $=UNIVERSAL::isa(ref(Git::Error::Command), 'Git::Error::Command') from /opt/local/lib/perl5/vendor_perl/5.22/Error.pm:324
       in  .=CODE(0x7fa8a23a74b8)(ref(Git::Error::Command), ref(SCALAR)) from /opt/local/lib/perl5/vendor_perl/5.22/Error.pm:345
        in  .=Error::throw(ref(Git::Error::Command)) from /opt/local/lib/perl5/site_perl/5.22/Git.pm:324
       in  $=CODE(0x7fa8a31d3db8)(ref(Git::Error::Command), undef, '') from /opt/local/lib/perl5/vendor_perl/5.22/Error.pm:354
      in  $=Scalar::Util::blessed(ref(Git::Error::Command)) from /opt/local/lib/perl5/vendor_perl/5.22/Error.pm:440
      in  $=UNIVERSAL::can(ref(Git::Error::Command), 'throw') from /opt/local/lib/perl5/vendor_perl/5.22/Error.pm:440
      in  .=Error::throw(ref(Git::Error::Command)) from /opt/local/lib/perl5/vendor_perl/5.22/Error.pm:442

Question: Can I get Git/SVN working on my MacBook? If not, are there alternatives that I can leverage?

Answer 1

Since your callstack includes =Git::_cmd_close(), know that Git included a bug since... forever, fixed only with Git 2.36 (Q2 2022).

It could lead to ignore other errors.
That being said, git-svn should be more stable in 2022.

See commit 6798b08 (01 Feb 2022) by Ævar Arnfjörð Bjarmason (avar).
^{(Merged by Junio C Hamano -- gitster -- in commit 834625b, 16 Feb 2022)}

perl Git.pm: don't ignore signalled failure in _cmd_close()

^{Signed-off-by: Ævar Arnfjörð Bjarmason}

Fix misbehavior in Git.pm that dates back to the very first version of the library in git.git added in b1edc53 ("Introduce Git.pm (v4)", 2006-06-24, Git v1.4.3-rc1 -- merge).
When we fail to execute a command we shouldn't ignore all signals, those can happen e.g. if abort() is called, or if the command segfaults.

Because of this we'd consider e.g. a command that died due to LSAN exiting with abort() successful, as is the case with the tests listed as running successfully with SANITIZE=leak in 9081a42 (checkout: fix , 2021-11-16, Git v2.35.0-rc0 -- merge listed in batch #2) (checkout: fix "branch info" memory leaks, 2021-11-16).
We did run them successfully, but only because we ignored these errors.

This was then made worse by the use of "abort_on_error=1" for LSAN added in 85b81b3 ("test-lib: set LSAN_OPTIONS to abort by default", 2017-09-05, Git v2.15.0-rc0 -- merge listed in batch #8).

All of our tests pass even without the SIGPIPE exception being added here, but as the code appears to have been trying to ignore it let's keep ignoring it for now.