Commit a series of patches to SVN without rebase

Commit a series of patches to SVN without rebase

[Jörg Sommer]

[-- Attachment #1: Type: text/plain, Size: 387 bytes --]

Hi,

I've a number of patches in git I want to send to a SVN repository. git
svn dcommit does a rebase after each commit which makes the whole commit
takes very long. Is it possible to skip the rebase? All patches are in
one branch without merges, a simple chain. Is it save to use --no-rebase
in this case?

Bye, Jörg
-- 
Der Klügere gibt so lange nach bis er der Dumme ist.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Commit a series of patches to SVN without rebase

[Eric Wong]

Jörg Sommer <joerg@alea.gnuu.de> wrote:
> Hi,
> 
> I've a number of patches in git I want to send to a SVN repository. git
> svn dcommit does a rebase after each commit which makes the whole commit
> takes very long. Is it possible to skip the rebase? All patches are in
> one branch without merges, a simple chain. Is it save to use --no-rebase
> in this case?

Right now, only if the changes don't depend on each other (they all
modify different files).

The following patch should allow dcommit of multiple changes that depend
on each other with --no-rebase.  --no-rebase was Karl's idea, and I've
never used it myself so I don't know how it works.

I don't have time to write a test case for --no-rebase at the
moment, but any reports/feedback would be helpful.  Thanks.

diff --git a/git-svn.perl b/git-svn.perl
index c51f1e7..9b1113a 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -418,7 +418,7 @@ sub cmd_dcommit {
 		warn "Attempting to commit more than one change while ",
 		     "--no-rebase is enabled.\n",
 		     "If these changes depend on each other, re-running ",
-		     "without --no-rebase will be required."
+		     "without --no-rebase may be required."
 	}
 	while (1) {
 		my $d = shift @$linear_refs or last;
@@ -453,6 +453,7 @@ sub cmd_dcommit {
 				                               $parents->{$d};
 			}
 			$_fetch_all ? $gs->fetch_all : $gs->fetch;
+			$last_rev = $cmt_rev;
 			next if $_no_rebase;
 
 			# we always want to rebase against the current HEAD,
@@ -512,7 +513,6 @@ sub cmd_dcommit {
 				$parents = \%p;
 				$linear_refs = \@l;
 			}
-			$last_rev = $cmt_rev;
 		}
 	}
 	unlink $gs->{index};

-- 
Eric Wong

Re: Commit a series of patches to SVN without rebase

[Jörg Sommer]

Hi Eric,

Eric Wong <normalperson@yhbt.net> wrote:
> Jörg Sommer <joerg@alea.gnuu.de> wrote:
>> I've a number of patches in git I want to send to a SVN repository. git
>> svn dcommit does a rebase after each commit which makes the whole commit
>> takes very long. Is it possible to skip the rebase? All patches are in
>> one branch without merges, a simple chain. Is it save to use --no-rebase
>> in this case?
>
> Right now, only if the changes don't depend on each other (they all
> modify different files).

May I ask you what the rational behind doing a rebase every time is? Is
it needed? Why is it not possible to send all commits and do one rebase
after the last one?

Bye, Jörg.
-- 
Wer A sagt, muß nicht B sagen. Er kann auch erkennen, daß A falsch war.
      	    	      	       	       	    	(Erich Kästner)

Re: Commit a series of patches to SVN without rebase

[Eric Wong]

Jörg Sommer <joerg@alea.gnuu.de> wrote:
> Hi Eric,
> 
> Eric Wong <normalperson@yhbt.net> wrote:
> > Jörg Sommer <joerg@alea.gnuu.de> wrote:
> >> I've a number of patches in git I want to send to a SVN repository. git
> >> svn dcommit does a rebase after each commit which makes the whole commit
> >> takes very long. Is it possible to skip the rebase? All patches are in
> >> one branch without merges, a simple chain. Is it save to use --no-rebase
> >> in this case?
> >
> > Right now, only if the changes don't depend on each other (they all
> > modify different files).
> 
> May I ask you what the rational behind doing a rebase every time is? Is
> it needed? Why is it not possible to send all commits and do one rebase
> after the last one?

Rebase is done to alert the user of potential conflicts before
attempting to commit them to a remote repository.  Formerly it was
done to prevent potential clobbering of upstream changes if
there were conflicts, but I think that's been rectified in recent
months.

-- 
Eric Wong