Re: git svn error "Not a valid object name"

[Thomas Rast <trast@student.ethz.ch>]

[+Cc Eric]

Adam Retter <adam@exist-db.org> 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