Problem with git-svn

Problem with git-svn

[John Wiegley]

Hello,

I've been using git-svn for a couple of weeks now quite happily.   
Then the other day I decided to start using "git-clone -l ..." in  
order to create a few concurrent topic branches.  I then moved to my  
canonical repository and did a "pull" from many of these topic branches.

So now I have a master git repository that reflects all of my  
accumulated work.  I want to reflect this up to my subversion  
repository.  However, it seems that doing all of that cloning and  
pulling has screwed up git-svn's tracking.  I get this error now when  
I try to dcommit:

Unable to extract revision information from commit  
865da18a70e8e93b1776864c73581198028e1190~1

The refid it's complaining about represents a pull of three changes  
from one of those topic branches:

commit 865da18a70e8e93b1776864c73581198028e1190
Merge: 42b0b95... f25fcef...
Author: John Wiegley <johnw@newartisans.com>
Date:   Thu May 3 00:17:17 2007 -0600

     Merge branch 'master' of /Users/johnw/src/ledger/master/

The refids that this refers to are also in my log, all with version  
information and log comments.

How do I get git-svn past this point?  I can't find any command that  
will make it functional again.  The last time this happened I just  
wiped my git repository and rebuilt it from scratch; but since people  
are tracking my git repository now, I'd rather now have to reset all  
of my refids (not to mention the sheer amount of time that it takes).

Thank you,
   John

Problem with git-svn

[Pascal Obry]

I'm trying to use a Subversion repository with Git. I had
great success with many repositories except one. This one
live since long time and as been migrated from CVS to
Subversion.

The current Subversion repository contains multiple projects.
Each project is under /trunk. While trying to import the project
PROJ:

  $ git svn clone svn+ssh://myserver/trunk/PROJ

I get:

Initialized empty Git repository in .git/
W: Ignoring error from SVN, path probably does not exist: (160013):
Filesystem has no item: File not found: revision 100, path '/trunk/PROJ'
Found possible branch point: svn+ssh://myserver/importfromcvs/trunk =>
svn+ssh://myserver/trunk/PROJ, 48467
Initializing parent: git-svn@48467
W: Ignoring error from SVN, path probably does not exist: (160013):
Filesystem has no item: File not found: revision 101, path
'/importfromcvs/trunk'
r9458 = b90789186c85a19a9f32ea6dc8a4259e2eadef67 (git-svn@48467)
        A       file.el

But file.el is not part of this project, it is part of another one
on the same Subversion repository. It looks like git-svn get confused
at some point. I've been trying to track this down, but since I've
never written a single Perl script that's not easy :(

Note that AFAIK each CVS modules have been imported into
/importfromcvs/trunk then move into /trunk/<MODULE_NAME>.

r48467 seem ok as a branch point:

<<
------------------------------------------------------------------------
r48468 | svn | 2007-05-09 15:10:54 +0200 (Wed, 09 May 2007) | 1 line
Changed paths:
   D /importfromcvs/trunk
   A /trunk/PROJ (from /importfromcvs/trunk:48467)

Importing module PROJ into SVN.
>>

So I'm looking for hints about the possible problem.

Note that I have tried to reproduce this with a small
script (using the same repository structure) but I was
not able.

Thanks,
Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Problem with git-svn

[Peter Baumann]

On Sun, Dec 16, 2007 at 11:30:04AM +0100, Pascal Obry wrote:
> 
> I'm trying to use a Subversion repository with Git. I had
> great success with many repositories except one. This one
> live since long time and as been migrated from CVS to
> Subversion.
> 
> The current Subversion repository contains multiple projects.
> Each project is under /trunk. While trying to import the project
> PROJ:
> 
>   $ git svn clone svn+ssh://myserver/trunk/PROJ
> 
> I get:
> 
> Initialized empty Git repository in .git/
> W: Ignoring error from SVN, path probably does not exist: (160013):
> Filesystem has no item: File not found: revision 100, path '/trunk/PROJ'
> Found possible branch point: svn+ssh://myserver/importfromcvs/trunk =>
> svn+ssh://myserver/trunk/PROJ, 48467
> Initializing parent: git-svn@48467
> W: Ignoring error from SVN, path probably does not exist: (160013):
> Filesystem has no item: File not found: revision 101, path
> '/importfromcvs/trunk'
> r9458 = b90789186c85a19a9f32ea6dc8a4259e2eadef67 (git-svn@48467)
>         A       file.el
> 
> But file.el is not part of this project, it is part of another one
> on the same Subversion repository. It looks like git-svn get confused
> at some point. I've been trying to track this down, but since I've
> never written a single Perl script that's not easy :(
> 
> Note that AFAIK each CVS modules have been imported into
> /importfromcvs/trunk then move into /trunk/<MODULE_NAME>.
> 
> r48467 seem ok as a branch point:
> 
> <<
> ------------------------------------------------------------------------
> r48468 | svn | 2007-05-09 15:10:54 +0200 (Wed, 09 May 2007) | 1 line
> Changed paths:
>    D /importfromcvs/trunk
>    A /trunk/PROJ (from /importfromcvs/trunk:48467)
> 
> Importing module PROJ into SVN.
> >>
> 
> So I'm looking for hints about the possible problem.
> 
> Note that I have tried to reproduce this with a small
> script (using the same repository structure) but I was
> not able.
> 
> Thanks,
> Pascal.
> 

Eric made a fix[1] this week so git-svn won't get confused if e.g. trunk
gets deleted and later created (or e.g. moved). Could you check if it
also fixes your problem? At least there is some familiarity, because your
trunk/PROJ also get moved from outside a path git-svn isn't tracking.

-Peter

[1]: See this thread for more details
     http://thread.gmane.org/gmane.comp.version-control.git/67665

Re: Problem with git-svn

[Pascal Obry]

Pete,

> Eric made a fix[1] this week so git-svn won't get confused if e.g. trunk
> gets deleted and later created (or e.g. moved). Could you check if it
> also fixes your problem? At least there is some familiarity, because your
> trunk/PROJ also get moved from outside a path git-svn isn't tracking.
> 
> -Peter
> 
> [1]: See this thread for more details
>      http://thread.gmane.org/gmane.comp.version-control.git/67665

This fix is already installed into the Git version I'm using which is:

   git version 1.5.4.rc0.36.g7680

So there is something else...

Thanks,
Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Problem with git-svn

[Eric Wong]

Pascal Obry <pascal@obry.net> wrote:
> 
> I'm trying to use a Subversion repository with Git. I had
> great success with many repositories except one. This one
> live since long time and as been migrated from CVS to
> Subversion.
> 
> The current Subversion repository contains multiple projects.
> Each project is under /trunk. While trying to import the project
> PROJ:
> 
>   $ git svn clone svn+ssh://myserver/trunk/PROJ
> 
> I get:
> 
> Initialized empty Git repository in .git/
> W: Ignoring error from SVN, path probably does not exist: (160013):
> Filesystem has no item: File not found: revision 100, path '/trunk/PROJ'
> Found possible branch point: svn+ssh://myserver/importfromcvs/trunk =>
> svn+ssh://myserver/trunk/PROJ, 48467
> Initializing parent: git-svn@48467
> W: Ignoring error from SVN, path probably does not exist: (160013):
> Filesystem has no item: File not found: revision 101, path
> '/importfromcvs/trunk'
> r9458 = b90789186c85a19a9f32ea6dc8a4259e2eadef67 (git-svn@48467)
>         A       file.el
> 
> But file.el is not part of this project, it is part of another one
> on the same Subversion repository. It looks like git-svn get confused
> at some point. I've been trying to track this down, but since I've
> never written a single Perl script that's not easy :(

Hi,

Can you show me the output of `svn log -v -r9458 svn+ssh://myserver/' ?

Thanks.

> Note that AFAIK each CVS modules have been imported into
> /importfromcvs/trunk then move into /trunk/<MODULE_NAME>.
> 
> r48467 seem ok as a branch point:
> 
> <<
> ------------------------------------------------------------------------
> r48468 | svn | 2007-05-09 15:10:54 +0200 (Wed, 09 May 2007) | 1 line
> Changed paths:
>    D /importfromcvs/trunk
>    A /trunk/PROJ (from /importfromcvs/trunk:48467)
> 
> Importing module PROJ into SVN.
> >>

So did svn+ssh://importfromcvs/trunk/file.el at r9458?  If so, git-svn
is behaving as expected.  If not, can you tell me where "file.el" was at
r9458?

> 
> So I'm looking for hints about the possible problem.
> 
> Note that I have tried to reproduce this with a small
> script (using the same repository structure) but I was
> not able.

-- 
Eric Wong

Re: Problem with git-svn

[Pascal Obry]

Hi Eric,

> Can you show me the output of `svn log -v -r9458 svn+ssh://myserver/'?

$ svn log -v -r9458  svn+ssh://myserver/
------------------------------------------------------------------------
r9458 | (no author) | 1998-04-22 19:07:08 +0200 (Wed, 22 Apr 1998) | 1 line
Changed paths:
   A /importfromcvs
   A /importfromcvs/branches
   A /importfromcvs/tags
   A /importfromcvs/trunk

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

> So did svn+ssh://importfromcvs/trunk/file.el at r9458?  If so, git-svn
> is behaving as expected.  If not, can you tell me where "file.el" was at
> r9458?

file.el was not imported at r9458 but at r9459, just after the creation
of the /importfromcvs directories above.

------------------------------------------------------------------------
r9459 | author | 1998-04-22 19:07:08 +0200 (Wed, 22 Apr 1998) | 2 lines
Changed paths:
   A /importfromcvs/trunk/file.el

Initial revision

------------------------------------------------------------------------

Thanks,
Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Problem with git-svn

[Eric Wong]

Pascal Obry <pascal.obry@gmail.com> wrote:
> Hi Eric,
> 
> > Can you show me the output of `svn log -v -r9458 svn+ssh://myserver/'?
> 
> $ svn log -v -r9458  svn+ssh://myserver/
> ------------------------------------------------------------------------
> r9458 | (no author) | 1998-04-22 19:07:08 +0200 (Wed, 22 Apr 1998) | 1 line
> Changed paths:
>    A /importfromcvs
>    A /importfromcvs/branches
>    A /importfromcvs/tags
>    A /importfromcvs/trunk
> 
> New repository initialized by cvs2svn.
> ------------------------------------------------------------------------
> 
> > So did svn+ssh://importfromcvs/trunk/file.el at r9458?  If so, git-svn
> > is behaving as expected.  If not, can you tell me where "file.el" was at
> > r9458?
> 
> file.el was not imported at r9458 but at r9459, just after the creation
> of the /importfromcvs directories above.
> 
> ------------------------------------------------------------------------
> r9459 | author | 1998-04-22 19:07:08 +0200 (Wed, 22 Apr 1998) | 2 lines
> Changed paths:
>    A /importfromcvs/trunk/file.el
> 
> Initial revision
> 
> ------------------------------------------------------------------------

Ah, oops, I was off-by-one with the revision number.  But git-svn does
look to be doing the right thing here, because it followed history into
/importfromcvs/trunk/ and file.el was part of it.

-- 
Eric Wong

Re: Problem with git-svn

[Pascal Obry]

Eric,

> Ah, oops, I was off-by-one with the revision number.  But git-svn does
> look to be doing the right thing here, because it followed history into
> /importfromcvs/trunk/ and file.el was part of it.

Yes part of it but before the creation of the /importfromcvs/trunk/ that
was moved later as /trunk/PROJ.

In /importfromcvs/trunk/ there was many projects imported. One per one,
each time moving it into /trunk/PROJ.

If I look at history of /trunk/PROJ:

   $ svn log svn+ssh://myserver/trunk/PROJ

The last revision is 45775, so I think git-svn should not look past this
revision. So I'm very surprised by the current behavior and think it is
a bug to import file.el at revision 9458. Note that the workaround for
me is to use:

   $ git svn clone svn+ssh://myserver/trunk/PROJ --revision=45775:HEAD

But it would be lot cleaner to have git-svn handling this properly I think.

Thanks,
Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Problem with git-svn

[Pascal Obry]

Eric,

> Ah, oops, I was off-by-one with the revision number.  But git-svn does
> look to be doing the right thing here, because it followed history into
> /importfromcvs/trunk/ and file.el was part of it.

Yes part of it but before the creation of the /importfromcvs/trunk/ that
was moved later as /trunk/PROJ.

In /importfromcvs/trunk/ there was many projects imported. One per one,
each time moving it into /trunk/PROJ.

If I look at history of /trunk/PROJ:

   $ svn log svn+ssh://myserver/trunk/PROJ

The last revision is 45775, so I think git-svn should not look past this
revision. So I'm very surprised by the current behavior and think it is
a bug to import file.el at revision 9458. Note that the workaround for
me is to use:

   $ git svn clone svn+ssh://myserver/trunk/PROJ --revision=45775:HEAD

But it would be lot cleaner to have git-svn handling this properly I think.

Thanks,
Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Problem with git-svn

[Pascal Obry]

Pascal Obry a écrit :
> Yes part of it but before the creation of the /importfromcvs/trunk/ that
> was moved later as /trunk/PROJ.

I meant moved as /trunk/PROJ1 then /trunk/PROJ2... and so on.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Problem with git-svn

[Eric Wong]

Pascal Obry <pascal.obry@gmail.com> wrote:
> Eric,
> 
> > Ah, oops, I was off-by-one with the revision number.  But git-svn does
> > look to be doing the right thing here, because it followed history into
> > /importfromcvs/trunk/ and file.el was part of it.
> 
> Yes part of it but before the creation of the /importfromcvs/trunk/ that
> was moved later as /trunk/PROJ.
> 
> < I meant moved as /trunk/PROJ1 then /trunk/PROJ2... and so on.
>
> In /importfromcvs/trunk/ there was many projects imported. One per one,
> each time moving it into /trunk/PROJ.
> 
> If I look at history of /trunk/PROJ:
> 
>    $ svn log svn+ssh://myserver/trunk/PROJ
> 
> The last revision is 45775, so I think git-svn should not look past this
> revision. So I'm very surprised by the current behavior and think it is
> a bug to import file.el at revision 9458. Note that the workaround for
> me is to use:

Since r48468 was where /importfromcvs/trunk got renamed into /trunk/PROJ
(from your previous message http://mid.gmane.org/4764FE2C.1010103@obry.net)

/importfromcvs/trunk exists at r45775, but /trunk/PROJ does not; and
git-svn at least follows that (which is what I suppose everybody wants).

However...

Did /importfromcvs/trunk exist all the way between r9458 and r48468?  Or
was that directory replaced entirely by something else along the way?

git-svn may be following copy history too aggressively, in this case.

On the other hand, this was somewhat intended because it could also
be a way to track merges as "moving" tags[1].

>    $ git svn clone svn+ssh://myserver/trunk/PROJ --revision=45775:HEAD
> 
> But it would be lot cleaner to have git-svn handling this properly I think.

Does --no-follow-parent work in your case?  Or does it go too far
in stopping at r48468 (probably).

[1] - I follow a project that has a RELEASE branch that is occasionally
deleted and replaced with the contents of trunk.   git-svn will actually
import this as a merge commit with two parents:

  1. trunk (obviously)
  2. the previous RELEASE, which was deleted

This allows old (but deleted) history to still be visible, which is what
*I* always want.  However, it could cause undesired behavior in your
case...

Note that running 'svn log <URL of #2 case>' will NOT show what git-svn
log will show for two; and I think it's nice that git-svn will track
history that is harder to find with SVN

(which would require svn log -v <URL of #2 case>@<rev>).

Maybe another switch should be added (--merge-foster-parent?)

-- 
Eric Wong

Re: Problem with git-svn

[Pascal Obry]

Eric,

> Since r48468 was where /importfromcvs/trunk got renamed into /trunk/PROJ
> (from your previous message http://mid.gmane.org/4764FE2C.1010103@obry.net)
> 
> /importfromcvs/trunk exists at r45775, but /trunk/PROJ does not; and
> git-svn at least follows that (which is what I suppose everybody wants).

Right.

> However...
> 
> Did /importfromcvs/trunk exist all the way between r9458 and r48468?  Or
> was that directory replaced entirely by something else along the way?

It was replaced along the way. This very same tree /importfromcvs/trunk
was used to import completely unrelated projects. Then moved, so it did
not exist all the way.

In my case the previous version on this tree was 45546. There is nothing
in between 45546 and 45775 for example. So looking at any revision in
between return an error:

$ svn log -v svn+ssh://myserver/importfromcvs/trunk@45760
svn: File not found: revision 45760, path '/importfromcvs/trunk'

> git-svn may be following copy history too aggressively, in this case.

Looks like it is the case. Hence the reported errors:

W: Ignoring error from SVN, path probably does not exist: (160013):
Filesystem has no item: File not found: revision 100, path '/trunk/PROJ'

and

W: Ignoring error from SVN, path probably does not exist: (160013):
Filesystem has no item: File not found: revision 101, path
'/importfromcvs/trunk'

For sure there was no revision 101 on /importfromcvs/trunk:

$ svn log -v svn+ssh://myserver/importfromcvs/trunk@101
svn: File not found: revision 101, path '/importfromcvs/trunk'

> On the other hand, this was somewhat intended because it could also
> be a way to track merges as "moving" tags[1].
> 
>>    $ git svn clone svn+ssh://myserver/trunk/PROJ --revision=45775:HEAD
>>
>> But it would be lot cleaner to have git-svn handling this properly I think.
> 
> Does --no-follow-parent work in your case?  Or does it go too far
> in stopping at r48468 (probably).

No it works on my case. That's what I'm using to import the directory in
two steps. I just want to go to the bottom of this to see if we can
somehow improve git-svn.

> Maybe another switch should be added (--merge-foster-parent?)

I'm not sure to understand what you are proposing here. To look only at
parents that are directly "related" to the current branch ?

Thanks,
Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Problem with git-svn

[Boaz Stuller]

I'm having a problem with git-svn.  I was connecting to a remote svn
repository via the svn+ssh:// protocol using an embedded username in
the url, i.e svn+ssh://boazstuller@svn.example.com/some/complicated/path.
 When I upgraded to 1.6.0, 'git svn dcommit' stopped working and
instead kept asking me for a password.   I tracked the problem down to
the following commit:

commit ba24e7457aa1f958370bbb67dfb97e3ec806fd4a
Author: Eric Wong <normalperson@yhbt.net>
Date:   Thu Aug 7 02:06:16 2008 -0700
    git-svn: add ability to specify --commit-url for dcommit

I don't know perl, but the problem seems to be where around line 446,
'$gs->full_url' gets changed to  '$url'.  Apparently, $gs->full_url
contained the embedded username but $url has it stripped out, i.e
svn+ssh://svn.example.com/some/complicated/path , so ssh can't tell
what username I'm trying to log in as.

Best wishes,
Bo

Re: Problem with git-svn

[Eric Wong]

Boaz Stuller <boazstuller@gmail.com> wrote:
> I'm having a problem with git-svn.  I was connecting to a remote svn
> repository via the svn+ssh:// protocol using an embedded username in
> the url, i.e svn+ssh://boazstuller@svn.example.com/some/complicated/path.
>  When I upgraded to 1.6.0, 'git svn dcommit' stopped working and
> instead kept asking me for a password.   I tracked the problem down to
> the following commit:
> 
> commit ba24e7457aa1f958370bbb67dfb97e3ec806fd4a
> Author: Eric Wong <normalperson@yhbt.net>
> Date:   Thu Aug 7 02:06:16 2008 -0700
>     git-svn: add ability to specify --commit-url for dcommit
> 
> I don't know perl, but the problem seems to be where around line 446,
> '$gs->full_url' gets changed to  '$url'.  Apparently, $gs->full_url
> contained the embedded username but $url has it stripped out, i.e
> svn+ssh://svn.example.com/some/complicated/path , so ssh can't tell
> what username I'm trying to log in as.

Hi Boaz, thanks for tracking this down.  The following patch should
fix your issue (and another potential one I noticed).

I've lightly tested it and it appears to work for me.

>From de9e79c4a7bdec5481dc0d19ae21ced3a403c0c9 Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Wed, 20 Aug 2008 00:30:06 -0700
Subject: [PATCH] git-svn: fix dcommit to urls with embedded usernames

Don't rely on the extracted URL from working_head_info since
that has the username removed.  Instead use the $gs->full_url
method (as before with ba24e7457aa1f958370bbb67dfb97e3ec806fd4a)
to give us the URL to commit to if --commit-url is not
specified.

Aditionally, since we clean usernames from URLs, checking the
URL after rebase can fail because it doesn't match the URL we
used to commit; so unconditionally provide a username-free
URL for checking the result of the refetch.

Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
 git-svn.perl |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/git-svn.perl b/git-svn.perl
index 099fd02..7a1d26d 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -421,7 +421,7 @@ sub cmd_dcommit {
 	$head ||= 'HEAD';
 	my @refs;
 	my ($url, $rev, $uuid, $gs) = working_head_info($head, \@refs);
-	$url = $_commit_url if defined $_commit_url;
+	$url = defined $_commit_url ? $_commit_url : $gs->full_url;
 	my $last_rev = $_revision if defined $_revision;
 	if ($url) {
 		print "Committing to $url ...\n";
@@ -437,6 +437,8 @@ sub cmd_dcommit {
 		     "If these changes depend on each other, re-running ",
 		     "without --no-rebase may be required."
 	}
+	my $expect_url = $url;
+	Git::SVN::remove_username($expect_url);
 	while (1) {
 		my $d = shift @$linear_refs or last;
 		unless (defined $last_rev) {
@@ -511,9 +513,9 @@ sub cmd_dcommit {
 					  $gs->refname,
 					  "\nBefore dcommitting";
 				}
-				if ($url_ ne $url) {
+				if ($url_ ne $expect_url) {
 					fatal "URL mismatch after rebase: ",
-					      "$url_ != $url";
+					      "$url_ != $expect_url";
 				}
 				if ($uuid_ ne $uuid) {
 					fatal "uuid mismatch after rebase: ",
-- 
Eric Wong

Re: Problem with git-svn

[Boaz Stuller]

On Wed, Aug 20, 2008 at 4:11 AM, Eric Wong <normalperson@yhbt.net> wrote:
> Boaz Stuller <boazstuller@gmail.com> wrote:
>> I'm having a problem with git-svn.  I was connecting to a remote svn
>> repository via the svn+ssh:// protocol using an embedded username in
>> the url, i.e svn+ssh://boazstuller@svn.example.com/some/complicated/path.
>>  When I upgraded to 1.6.0, 'git svn dcommit' stopped working and
>> instead kept asking me for a password.   I tracked the problem down to
>> the following commit:
>>
>> commit ba24e7457aa1f958370bbb67dfb97e3ec806fd4a
>> Author: Eric Wong <normalperson@yhbt.net>
>> Date:   Thu Aug 7 02:06:16 2008 -0700
>>     git-svn: add ability to specify --commit-url for dcommit
>>
>> I don't know perl, but the problem seems to be where around line 446,
>> '$gs->full_url' gets changed to  '$url'.  Apparently, $gs->full_url
>> contained the embedded username but $url has it stripped out, i.e
>> svn+ssh://svn.example.com/some/complicated/path , so ssh can't tell
>> what username I'm trying to log in as.
>
> Hi Boaz, thanks for tracking this down.  The following patch should
> fix your issue (and another potential one I noticed).
>
> I've lightly tested it and it appears to work for me.
>

I only tested with a couple commits too, but your patch works
perfectly for me.

Thanks,
Bo

Re: Problem with git-svn

[Eric Wong]

Boaz Stuller <boazstuller@gmail.com> wrote:
> On Wed, Aug 20, 2008 at 4:11 AM, Eric Wong <normalperson@yhbt.net> wrote:
> > Boaz Stuller <boazstuller@gmail.com> wrote:
> >> I'm having a problem with git-svn.  I was connecting to a remote svn
> >> repository via the svn+ssh:// protocol using an embedded username in
> >> the url, i.e svn+ssh://boazstuller@svn.example.com/some/complicated/path.
> >>  When I upgraded to 1.6.0, 'git svn dcommit' stopped working and
> >> instead kept asking me for a password.   I tracked the problem down to
> >> the following commit:
> >>
> >> commit ba24e7457aa1f958370bbb67dfb97e3ec806fd4a
> >> Author: Eric Wong <normalperson@yhbt.net>
> >> Date:   Thu Aug 7 02:06:16 2008 -0700
> >>     git-svn: add ability to specify --commit-url for dcommit
> >>
> >> I don't know perl, but the problem seems to be where around line 446,
> >> '$gs->full_url' gets changed to  '$url'.  Apparently, $gs->full_url
> >> contained the embedded username but $url has it stripped out, i.e
> >> svn+ssh://svn.example.com/some/complicated/path , so ssh can't tell
> >> what username I'm trying to log in as.
> >
> > Hi Boaz, thanks for tracking this down.  The following patch should
> > fix your issue (and another potential one I noticed).
> >
> > I've lightly tested it and it appears to work for me.
> 
> I only tested with a couple commits too, but your patch works
> perfectly for me.

Junio: please apply my patch to maint, thank you.

-- 
Eric Wong