[+Cc Eric] Adam Retter <adam@xxxxxxxxxxxx> writes: > $ git svn init -t tags -b stable -T trunk > file:///home/ec2-user/svn-rsync/code new-git-repo > $ cd new-git-repo > $ git config svn-remote.svn.preserve-empty-dirs true > $ git config svn-remote.svn.rewriteRoot https://svn.code.sf.net/p/exist/code > $ git svn fetch -A /home/ec2-user/.svn2git/authors.txt > > It all started well and was running away for quite some hours, when > the following error occurred: > > fatal: Not a valid object name > ls-tree -z ./webapp/api/: command returned error: 128 The important observation is that the object name is missing; the error is misleading in that it simply tells us that what is *taken* for the object name is invalid. There appear to be only two uses of ls-tree -z without further options in git-svn, namely: SVN/Fetcher.pm:165: my ($tree) = (command('ls-tree', '-z', $self->{c}, "./$gpath") SVN/Fetcher.pm:197: ($mode, $blob) = (command('ls-tree', '-z', $self->{c}, "./$gpath In either one, $self->{c} is empty if they fail in this way. And that seems to come from 'sub new', which says if (exists $git_svn->{last_commit}) { $self->{c} = $git_svn->{last_commit}; $self->{empty_symlinks} = _mark_empty_symlinks($git_svn, $switch_path); } So for some reason new() thinks it's okay to leave $self->{c} uninitialized, but delete_entry() and open_file() expect it to be set. It does seem that the ls-tree $self->{c} usage in both of those routines is from approximately the beginning of time. See these two, if you compiled your git with log -L: git log -L:delete_entry:git-svn.perl a6180325^ git log -L:open_file:git-svn.perl a6180325^ Unfortunately that's pretty much where my git-svn knowledge ends. Maybe Eric can help? -- Thomas Rast trast@{inf,student}.ethz.ch -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html