git-svn dcommit fail

git-svn dcommit fail

[Dongsheng Song]

After some merge operation,

$ git-svn rebase
Current branch master is up to date.
$ git-svn dcommit
Unable to extract revision information from commit
f10ff0772f96ec434b27d47efaee082190bb8516~1

Thanks for some help.

---
Dongsheng

Re: git-svn dcommit fail

[Steven Grimm]

Dongsheng Song wrote:
> After some merge operation,

git-svn doesn't support nonlinear history in any of the official 
releases, though there will be some support in the next release (you can 
try it out by grabbing the latest version from git.git's master branch). 
If you don't want to run a prerelease version of git, you need to avoid 
doing non-squash merges into branches that you are going to check into 
an svn repository.

Squash merges (git merge --squash) work fine, though. They will be 
recorded in your history as a regular commit, not a merge, so git-svn 
won't be confused by them.

-Steve

Fwd: git-svn dcommit fail

[Kees-Jan Dijkzeul]

This one should have gone to the list. Sorry, Steven, for mailing privately.

---------- Forwarded message ----------
From: Kees-Jan Dijkzeul <k.j.dijkzeul@gmail.com>
Date: Jul 5, 2007 10:26 AM
Subject: Re: git-svn dcommit fail
To: Steven Grimm <koreth@midwinter.com>


On 7/5/07, Steven Grimm <koreth@midwinter.com> wrote:
> git-svn doesn't support nonlinear history in any of the official
> releases, though there will be some support in the next release (you can
> try it out by grabbing the latest version from git.git's master branch).

I just fetched the master branch. For me it is at commit
d44c782bbd6b0e806e056f9e8ff8cd8e426e67a3.
At this point, git-svn is identical to the one in 1.5.2.3.

I've attempted to use git to merge two subversion branches, but when
dcommitting attempts to commit the correct delta to the wrong branch,
and subsequently claims that "Your file or directory is probably out
of date" (which, in a weird way, makes sense).

I'd be happy to test this support for nonlinear history, but so far,
I've been unable to locate the correct commit.

Groetjes,

Kees-Jan

Re: Fwd: git-svn dcommit fail

[Junio C Hamano]

"Kees-Jan Dijkzeul" <k.j.dijkzeul@gmail.com> writes:

> I just fetched the master branch. For me it is at commit
> d44c782bbd6b0e806e056f9e8ff8cd8e426e67a3.

You must be kiding.  That was made on Jun 6, 2007, which is
ancient if not prehistoric in git timescale.

Could you double check?

Re: Fwd: git-svn dcommit fail

[Kees-Jan Dijkzeul]

On 7/5/07, Junio C Hamano <gitster@pobox.com> wrote:
> Could you double check?

*Blush*. I should have caught that one myself. I'm now at commit
114fd812f78ea375ee6782d4ff0203f3ae20b076, which still exhibits the
same problem.

Basically, the problem is as follows: My head commit is a merge:
$ git show HEAD
commit e135f26dbae66f539b486646a12aa51e71c196a1
Merge: bb8ac98... f453e1e...

Both parents are svn-commits.

When I do a dry-run, I get
$ git-svn dcommit -n
diff-tree e135f26dbae66f539b486646a12aa51e71c196a1~1
e135f26dbae66f539b486646a12aa51e71c196a1

As far as I'm concerned, this is correct. This is the delta that
should be committed to the svn branch who's head is
e135f26dbae66f539b486646a12aa51e71c196a1~1 (obviously).

However, function "working_head_info" of git-svn returns the other
parent as the working head. As a result, committing the diff to svn
fails.

I've observed that the call to cmt_metadata("$d~1") (line 382 of
git-svn) does return the correct svn branch, so it would seem to me
that it makes much more sense to commit to that.

Any thoughts, tips, tricks?

Thanks!

Kees-Jan

Re: Fwd: git-svn dcommit fail

[Steven Grimm]

Kees-Jan Dijkzeul wrote:
> Basically, the problem is as follows: My head commit is a merge:
> $ git show HEAD
> commit e135f26dbae66f539b486646a12aa51e71c196a1
> Merge: bb8ac98... f453e1e...
>
> Both parents are svn-commits.

That seems to be a case that the current merge support in git-svn can't 
handle. I'll refer you to the test I did when the merge support first 
landed on the mailing list:

http://www.spinics.net/lists/git/msg33628.html

The current code seems to be aimed at using branches for local 
development on the git side rather than dealing with relationships 
between multiple svn branches.

I'll also point out this utility, which may be of use to you. It is not 
perfect but it works.

http://www.spinics.net/lists/git/msg29119.html

-Steve