Re: git-svn bug?

"Troy Telford" [off-list ref] writes:

(using git 1.4.4, svn 1.3.1 on a SLES 10 box)
fatal: Not a valid object name 92e2e0c50bbbacb0a3426b2c0f8b3e043eb4830a~1
32768 at /usr/lib/perl5/5.8.8/Memoize.pm line 269
...
I couldn't find an object named
"92e2e0c50bbbacb0a3426b2c0f8b3e043eb4830a~1" in .git/

Troy, do you have object 92e2e0c5?  Is it a root commit (i.e. a
commit that does not have a parent)? 

The only place that mentions ~1 in git-svn seems to be inside
dcommit but it seems that it unconditionally appends ~1 to the
rev.  I do not know how the code guarantees it does not go down
to the root commit.

Eric, any clues?

Troy Telford [off-list ref] wrote:

My 'dummy' repo was imported using git-svn.
My 'real' repo was imported using git-svnimport.

Having not read any of the code, I'm just taking a wild guess; but is it  
reasonable to say that since the repository was originally imported to git  
using git-svnimport (rather than git-svn), git-svn doesn't have some of  
the data it needs to push to the remote svn repo?

Exactly, git-svn needs the git-svn-id: lines at the end of each commit
for 'commit' and 'dcommit' to work.  So using a repo created by
git-svnimport will not work.

'commit-diff' will work, however it's intended as a low-level command
('commit' should be that, too).

Would it be reasonable to use git-svn to import the SVN repository into a  
new git repo, and then rebase from the old git-svnimport'ed repo into the  
new git-svn imported one?  (did that even make sense?!?)

Yes, something along those lines would work.

-- 

On Fri, 17 Nov 2006 01:55:10 -0700, Eric Wong [off-list ref]  
wrote:

dcommit expects to be run on a git-svn fetch-ed HEAD that is linear
superset of remotes/git-svn.  That is: remotes/git-svn..HEAD should
(ideally) contain no merges, and no root commits.  git-svn currently
does no checking for root commits, but it should.

This commit is missing the git-svn-id: line at the bottom.  If you
simply left it out (private svn repository info), can you check that the
URL in this line is actually for the SVN repository you want to commit
to?

I didn't remove anything, but I did double-check and the URL is correct.   
But the following may shed light on why there is no git-svn-id anywhere:   
IIRC, this is how my current repository came to be (from the very  
beginning):
1.)  Way back when, before I even started on the project, it started life  
as a CVS repository
2.)  Was converted from CVS -> SVN in early '05 (pre-git)
3.)  I converted from SVN->git in Nov/Dec '05 (using git-svnimport.  I'm  
not sure git-svn was available at the time.)
4.)  The svn repository is still around, and I need to interoperate with  
the svn repository on occasion.  I read about the new (at the time)  
'git-svn', and decided to give it a try.
5.)  I start with my pre-existing git repository, running:

   git svn init <url>
   git svn fetch
   git checkout -b master svn
   git rebase remotes/git-svn

It seems like your usage of dcommit would actually cause the issue
you're experiencing to be triggered on the dummy repository, and not the
real one.  My other guess would be that you somehow merged commits from
your dummy svn repo into your master branch.

I need to work on being more clear; sorry about that.  Here's what I did  
with my 'dummy' repository
1. create a new (empty) svn repository
2. imported it into a new git repository using git-svn
3. added a few files that were just sitting in $HOME, then modified them,  
removed some, added others, etc.  (using both git-svn and subversion)
4. verified everything was working as I expected it to.  (and if not,  
figure out why I was wrong).

My 'dummy' repo was imported using git-svn.
My 'real' repo was imported using git-svnimport.

Having not read any of the code, I'm just taking a wild guess; but is it  
reasonable to say that since the repository was originally imported to git  
using git-svnimport (rather than git-svn), git-svn doesn't have some of  
the data it needs to push to the remote svn repo?

Would it be reasonable to use git-svn to import the SVN repository into a  
new git repo, and then rebase from the old git-svnimport'ed repo into the  
new git-svn imported one?  (did that even make sense?!?)
-- 

On Wed, 15 Nov 2006 14:43:30 -0700, Junio C Hamano [off-list ref] wrote:

"Troy Telford" [off-list ref] writes:

quoted

(using git 1.4.4, svn 1.3.1 on a SLES 10 box)
fatal: Not a valid object name  
92e2e0c50bbbacb0a3426b2c0f8b3e043eb4830a~1
32768 at /usr/lib/perl5/5.8.8/Memoize.pm line 269
...
I couldn't find an object named
"92e2e0c50bbbacb0a3426b2c0f8b3e043eb4830a~1" in .git/

Troy, do you have object 92e2e0c5?  Is it a root commit (i.e. a
commit that does not have a parent)?

I'll have to admit I'm stabbing in the dark on how to get the correct  
answer this, but here goes:

* `git cat-file -t 92e2e0...` returns 'commit'
* 'git cat-file -p 92e2e0...` returns: (minus the header/footer asterisks)
*********************************************
tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
author unknown <unknown> 961088898 +0000
committer unknown <unknown> 961088898 +0000

New repository initialized by cvs2svn.
*********************************************
-- 

Sorry for the late replies, I've been caught up with other things.

Troy Telford [off-list ref] wrote:

On Wed, 15 Nov 2006 14:43:30 -0700, Junio C Hamano [off-list ref] wrote:

quoted

"Troy Telford" [off-list ref] writes:

quoted

(using git 1.4.4, svn 1.3.1 on a SLES 10 box)
fatal: Not a valid object name  
92e2e0c50bbbacb0a3426b2c0f8b3e043eb4830a~1
32768 at /usr/lib/perl5/5.8.8/Memoize.pm line 269
...
I couldn't find an object named
"92e2e0c50bbbacb0a3426b2c0f8b3e043eb4830a~1" in .git/

Troy, do you have object 92e2e0c5?  Is it a root commit (i.e. a
commit that does not have a parent)?

dcommit expects to be run on a git-svn fetch-ed HEAD that is linear
superset of remotes/git-svn.  That is: remotes/git-svn..HEAD should
(ideally) contain no merges, and no root commits.  git-svn currently
does no checking for root commits, but it should.

I'll have to admit I'm stabbing in the dark on how to get the correct  
answer this, but here goes:

* `git cat-file -t 92e2e0...` returns 'commit'
* 'git cat-file -p 92e2e0...` returns: (minus the header/footer asterisks)
*********************************************
tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
author unknown <unknown> 961088898 +0000
committer unknown <unknown> 961088898 +0000

New repository initialized by cvs2svn.
*********************************************

This commit is missing the git-svn-id: line at the bottom.  If you
simply left it out (private svn repository info), can you check that the
URL in this line is actually for the SVN repository you want to commit
to?

It seems like your usage of dcommit would actually cause the issue
you're experiencing to be triggered on the dummy repository, and not the
real one.  My other guess would be that you somehow merged commits from
your dummy svn repo into your master branch.

--