# git svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor

3 messages from 2015-01-08 to 2015-01-14. Participants: Minty, Eric Wong.
Thread: https://gitlist.dev/t/38309

## Minty, 2015-01-08 12:43

Subject: git svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor
Message-ID: <CANBgh6jyvbquuAwpWuuG4mJ3uZgajchcsJnttn4tN+LNE6EK+Q@mail.gmail.com>
URL: https://gitlist.dev/e/CANBgh6jyvbquuAwpWuuG4mJ3uZgajchcsJnttn4tN%2BLNE6EK%2BQ%40mail.gmail.com

```
I appear to have hit a bug (or have data that the code fails on) while
importing an SVN repo to git.

I'm wondering if there is anything I can do to help find / fix the
cause, given I appear to have a fail-case.

Sadly I can't supply the SVN repo as the code is private.

What I did:

git svn clone https://www.example.com/dshfkjhfsjhsdkjfhsdf/nameofrepo

What I'm running:

MacOS Yosemite 10.10.1 (14B25)

§ git --version
git version 2.2.1

Built via MacPorts using: sudo port install git +svn

and updated today to the latest available.

The process was running for a few minutes and does appear to have
imported a lot.  The last few lines of output, including the error
(with paths/names anonymised)

r869 = 9823c89bbdfa9d51aeb0a16c539049ae96nd5d62 (refs/remotes/git-svn)
    D    path/to/stuff/Example1.java
    D    path/to/stuff/Example2.java
W: -empty_dir: path/to/stuff/Example1.java
W: -empty_dir: path/to/stuff/Example2.java
r870 = b1f06434b0b2f37a11be2ee5dfc6175bjs348545 (refs/remotes/git-svn)
write .git/Git_svn_hash_BmjclS: Bad file descriptor
 at /opt/local/lib/perl5/vendor_perl/5.16.3/darwin-thread-multi-2level/SVN/Ra.pm
line 623.

Any advice / pointers would be welcome -- I'd be happy to run any
tests & I'm reasonably comfortable coding in Perl so happy to poke
around where I can.

I've been using git for year (thanks! it rocks) and hoping I can avoid
having to (re)learn too much about SVN.

```

## Minty, 2015-01-08 17:51

Subject: Re: git svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor
Message-ID: <CANBgh6gJ3dFK7uxWQKYu83H_Hz_LNPpomnNM_mULCe7Om=5aDg@mail.gmail.com>
URL: https://gitlist.dev/e/CANBgh6gJ3dFK7uxWQKYu83H_Hz_LNPpomnNM_mULCe7Om%3D5aDg%40mail.gmail.com
In-Reply-To: <CANBgh6jyvbquuAwpWuuG4mJ3uZgajchcsJnttn4tN+LNE6EK+Q@mail.gmail.com>

```
On Thu, Jan 8, 2015 at 12:43 PM, Minty <mintywalker@gmail.com> wrote:
> git svn clone https://www.example.com/dshfkjhfsjhsdkjfhsdf/nameofrepo
>
> r869 = 9823c89bbdfa9d51aeb0a16c539049ae96nd5d62 (refs/remotes/git-svn)
>     D    path/to/stuff/Example1.java
>     D    path/to/stuff/Example2.java
> W: -empty_dir: path/to/stuff/Example1.java
> W: -empty_dir: path/to/stuff/Example2.java
> r870 = b1f06434b0b2f37a11be2ee5dfc6175bjs348545 (refs/remotes/git-svn)
> write .git/Git_svn_hash_BmjclS: Bad file descriptor
>  at /opt/local/lib/perl5/vendor_perl/5.16.3/darwin-thread-multi-2level/SVN/Ra.pm
> line 623.

fyi - tried the same repo, same command under Ubuntu 14.04, using the
stock git-svn deb & it worked.

happy to help try debugging the problem on MacOS if anyone wants to
give me a pointer, but otherwise I'm good.

Thanks.

```

## Eric Wong, 2015-01-14 01:50

Subject: Re: git svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor
Message-ID: <20150114015050.GA9134@dcvr.yhbt.net>
URL: https://gitlist.dev/e/20150114015050.GA9134%40dcvr.yhbt.net
In-Reply-To: <CANBgh6jyvbquuAwpWuuG4mJ3uZgajchcsJnttn4tN+LNE6EK+Q@mail.gmail.com>

```
Minty <mintywalker@gmail.com> wrote:
> § git --version
> git version 2.2.1

What about "git svn --version" ?
(it'll display the SVN binding version, too)

> Any advice / pointers would be welcome -- I'd be happy to run any
> tests & I'm reasonably comfortable coding in Perl so happy to poke
> around where I can.

Great to know.  Unfortunately, I no longer have access to the repo where
I encountered the problem and haven't been able to reproduce it again,
either.

The first step is to find a (preferably) fast way to reproduce the issue
consistently.  If you can isolate which revisions and change patterns in
your private repo cause it, it should be possible to create a public
repo without confidential data in it which reproduces the problem.

```
