I've got a repository I've converted over to git from svn.  (using

git-svn.  since there's only been one branch, I figured I could skip

git-svnimport).
For quite a while, all I did was fetch/rebase from the svn repository to

my git repository; all of my own work was committed to the git repository;

none of the changes were commited to the svn repository.
Then came the time to commit changes from my git repository to the svn

repository.
Being somewhat cautious, I created an empty 'dummy' svn repository and

familiarize myself with using git-svn to commit from git -> svn.
I ran:

git-svn fetch

git-svn rebase remotes/git-svn (already updated)

git-svn dcommit (to push my changes to the svn repository)
Everything seemed to work fine with the dummy repository.
Encouraged, I did the same with the 'real' repository, and received the

following error:

(Using git 1.4.3.5, svn 1.4.0 on a Gentoo box)

fatal: Not a valid object name 92e2e0c50bbbacb0a3426b2c0f8b3e043eb4830a~1

32768 at /usr/lib64/perl5/5.8.8/Memoize.pm line 269
(using git 1.4.4, svn 1.3.0 on a SLES 9 SP3 box)

fatal: Not a valid object name 92e2e0c50bbbacb0a3426b2c0f8b3e043eb4830a~1

32768 at /usr/lib/perl5/5.8.3/Memoize.pm line 269
(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 had NFS mounted the git repository, so the SLES 9 was local the other

two were NFS.  In any event, the error seems to be essentially identical

on every platform I've tried.
Additionally, I had created three branches for the purpose of pushing my

changes to svn:

master (used for my own development)

svn (created using git checkout -b svn remotes/git-svn -- basically only

what is in svn)

merge (git checkout -b merge svn; git rebase master)
`git diff-tree merge master | wc -l` returns 0 (which I assume means no

changes)

`git diff-tree svn merge | wc -l` returns 44 (again, I assume this mea...
[ message continues ]

I always send commits as:
git-svn dcommit remotes/git-svn..master
Possibly replacing master with whatever git branch I'm working on.

One nice thing about this approach is that you can sort of preview the

commit as:
  git diff remotes/git-svn..master
[but that just shows overall diffs and git-svn dcommit will apply each

commit in master separately to svn]
+ seth

-

I get essentially the same error:
Since I actually checked out a branch, I assume that
     git diff remotes/git-svn..svn
should be empty, right?
And if that's the case `git diff svn..master` should be identical to `git

diff remotes/git-svn..svn`?
If I write the diff to a file, it is about 294k in size.  Also worth

mentioning is that I'm also tracking binary files in the git repository as

well.  It's for an RPM tree, so I have the (binary) package source

tarballs (in a few cases >100 MB tarball) and their corresponding (text)

patches and .spec files.

--

Troy Telford

-

Or just:
   git-svn dcommit remotes/git-svn..
Or see the log and patch of each commit on the current branch:
   git log -p remotes/git-svn..
--

Shawn.

-

Yes, but be warned.  As I just discovered, dcommit always commits up

to the HEAD of the current branch.  So I just did:
git-svn dcommit remotes/git-svn..HEAD~3
And the ~3 was ignored.  :-(

Not a bug, as the doc says that dcommit operates on HEAD, but it would

be convenient to have this work -- especially since reviewing with

diff (or better log -p) seems natural.
+ seth

-

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?
-

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.

*********************************************

--

Troy Telford

-

Sorry for the late replies, I've been caught up with other things.
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
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.
--

Eric Wong

-

On Fri, 17 Nov 2006 01:55:10 -0700, Eric Wong <normalperson@yhbt.net>  
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
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?!?)

--

Troy Telford

-

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
Yes, something along those lines would work.
--

Eric Wong

-