Eric Wong <normalperson@xxxxxxxx> wrote:
> Eddy Petrișor <eddy.petrisor@xxxxxxxxx> wrote:
> > - use submodules for externals
>
> I'm not sure if mapping submodules to externals is a good idea
> because externals don't require exact revisions and submodules do.
> There's also an issue I was just made aware of two days ago with
> submodules and git-svn that I haven't had time to work on.
Definitely a complex problem. A new submodule from git mapping to an
new svn:external probably doesn't work very well, either. There's also
UI/policy issues with creating a new directory/branch in SVN to house
the external. It will also will not work for (the few) projects that
are using the root of the SVN repository directly.
> Another user also privately reported a bug to me about git-svn having
> trouble dcommitting when using submodules. I've attached the test case
> here in case you have any thoughts on how to handle this (I think the
> easiest would be to ignore submodules on dcommit entirely).
Well, I'm stuck on this problem. Since that user that reported this
emailed me privately, I'm bcc-ing him on this issue, too.
I've tried the following, and it gets the commit into SVN without the
submodules using dcommit.
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3364,7 +3364,7 @@ sub new {
sub generate_diff {
my ($tree_a, $tree_b) = @_;
- my @diff_tree = qw(diff-tree -z -r);
+ my @diff_tree = qw(diff-tree --ignore-submodules -z -r);
if ($_cp_similarity) {
push @diff_tree, "-C$_cp_similarity";
} else {
However, all is not well. The rebase/reset step in dcommit gets
triggered with a rebase because the submodule is dropped from the tree
when we refetch the commit from SVN.
The simplest would be to say we don't support mixing submodules with
git-svn. I'm fine with this statement.
The clever way would be introducing a custom revprop for git-svn
to use to declare submodule dependencies. Then git-svn can
recreate the information needed for a revprop on fetch.
That would mean regular SVN users would not get access to submodules.
Cutting SVN users off from being able to effectively use an SVN repo
doesn't make sense to me. The project might as well be using git
entirely and ditch SVN. Of course, some PHB somewhere will want to keep
the project on SVN even when all the developers are using git-svn...
Since gmane seems to have broken the attachment I previously sent,
here again is the patch inlined:
>From bddc57078188d4798a9a74401aa0da8ca35a4db1 Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@xxxxxxxx>
Date: Fri, 29 Aug 2008 02:09:50 -0700
Subject: [PATCH] git-svn: Add submodule ignore test
---
t/t9126-git-svn-submodule.sh | 44 ++++++++++++++++++++++++++++++++++++++++++
1 files changed, 44 insertions(+), 0 deletions(-)
create mode 100644 t/t9126-git-svn-submodule.sh
diff --git a/t/t9126-git-svn-submodule.sh b/t/t9126-git-svn-submodule.sh
new file mode 100644
index 0000000..c4b3489
--- /dev/null
+++ b/t/t9126-git-svn-submodule.sh
@@ -0,0 +1,44 @@
+#!/bin/sh
+# Copyright (c) 2008 Eric Wong
+
+test_description='git-svn submodule'
+
+. ./lib-git-svn.sh
+
+test_expect_success 'setup repo' 'svn co "$svnrepo" svnfoo'
+
+test_expect_success 'add files to svn repo' '
+ touch svnfoo/foo.txt
+ (cd svnfoo && svn add * && svn commit -m "test commit")
+ '
+
+test_expect_success 'git-svn clone the svn repo' '
+ git-svn clone "$svnrepo" gitfoo
+ '
+
+test_expect_success 'create a git repo to include as a submodule' '
+ mkdir git_to_include
+ (
+ cd git_to_include &&
+ git init &&
+ echo "This is another file" > another.txt &&
+ git add another.txt &&
+ git commit -a -m "Adding file to submodule" &&
+ git log
+ )
+ '
+
+test_expect_success 'add the submodule' '
+ (
+ cd gitfoo &&
+ git submodule add "$remove_trash"/git_to_include \
+ git_as_submodule &&
+ git commit -a -m "Adding submodule"
+ )
+ '
+
+test_expect_success 'try to rebase and commit' '
+ ( cd gitfoo && git svn rebase && git svn dcommit )
+ '
+
+test_done
--
Eric Wong
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
