git-svn messing up merge commits on dcommit

git-svn messing up merge commits on dcommit

[Björn Steinbrink]

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

Hi Eric,

I have two "test cases" here (attached), which I actually wrote months
ago, but forgot to sent, as I wanted to clean them up/turn them into
something suitable for the test suite, but honestly, I'll probably never
get around to do that, so here they are, as they are. They show git-svn
messing up merge commits when dcommitting a branch that is not
up-to-date WRT the svn repo.

The basic history for both cases (before dcommit) is:

        C---D (master)
       /   /
      /---E (side)
     /
A---B (trunk)
     \
      X (revision in SVN, not yet fetched)

So the dcommit (which would send C and D to the svn repo) needs to
"rebase" C and D.

In the first test case, this rebasing causes conflicts, and leads to a
linearized history:

      E (side)
     /
A---B---X---C' (trunk)
             \
              D (master)

The merge is broken apart. This is probably expected, but I thought I'd
tell anyway.


The second test case is a bit more interesting, there are no conflicts
between the local commits to be dcommitted and the new commit X in the
svn repo. In this case, git-svn manages to dcommit the merge commit just
fine, keeping the history correct, but it messes the merge commit's
commit message up. So the history becomes:

A---B---X---C'--D' (trunk) (master)
     \         /
      --------E (side)

But D' has the same commit message as C/C', not the one from D.

I hope that makes any sense to you (or you can figure it out from the
testing scripts).

Björn

[-- Attachment #2: test --]
[-- Type: text/plain, Size: 582 bytes --]

#!/bin/sh
mkdir git-svn-test
cd git-svn-test

SVN="file://$PWD/svnrepo"
svnadmin create svnrepo
svn co "$SVN" co
cd co
svn mkdir trunk tags branches
svn ci -m init

echo 123 > trunk/foo
svn add trunk/foo
svn ci -m "SVN 1"

cd ..

git svn clone -s "$SVN" git

cd co
echo 456 >> trunk/foo
svn ci -m "SVN 2"
cd ..

cd git
git checkout -b side
echo 123 >> foo
git add foo
git commit -m "On side"
git checkout master
echo 123 > foo3
git add foo3
git commit -m "On master"
git merge --no-ff side
gitk --all&
git svn dcommit
echo resolved > foo
git add -u
git rebase --continue
gitk --all

[-- Attachment #3: test2 --]
[-- Type: text/plain, Size: 532 bytes --]

#!/bin/sh
mkdir git-svn-test
cd git-svn-test

SVN="file://$PWD/svnrepo"
svnadmin create svnrepo
svn co "$SVN" co
cd co
svn mkdir trunk tags branches
svn ci -m init

echo 123 > trunk/foo
svn add trunk/foo
svn ci -m "SVN 1"

cd ..

git svn clone -s "$SVN" git

cd co
echo 456 >> trunk/foo
svn ci -m "SVN 2"
cd ..

cd git
git checkout -b side
echo 123 >> foo2
git add foo2
git commit -m "On side"
git checkout master
echo 123 > foo3
git add foo3
git commit -m "On master"
git merge --no-ff side
gitk --all&
git svn dcommit
gitk --all&

Re: git-svn messing up merge commits on dcommit

[Eric Wong]

Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> Hi Eric,
> 
> I have two "test cases" here (attached), which I actually wrote months
> ago, but forgot to sent, as I wanted to clean them up/turn them into
> something suitable for the test suite, but honestly, I'll probably never
> get around to do that, so here they are, as they are. They show git-svn
> messing up merge commits when dcommitting a branch that is not
> up-to-date WRT the svn repo.
> 
> The basic history for both cases (before dcommit) is:
> 
>         C---D (master)
>        /   /
>       /---E (side)
>      /
> A---B (trunk)
>      \
>       X (revision in SVN, not yet fetched)
> 
> So the dcommit (which would send C and D to the svn repo) needs to
> "rebase" C and D.
> 
> In the first test case, this rebasing causes conflicts, and leads to a
> linearized history:
> 
>       E (side)
>      /
> A---B---X---C' (trunk)
>              \
>               D (master)
> 
> The merge is broken apart. This is probably expected, but I thought I'd
> tell anyway.

As noted in the CAVEATS section of the manpage, pull/merge isn't
recommended with dcommit because it generates non-linear history.

Keep in mind this was written before SVN got merge tracking support, but
I haven't been particularly motivated to revisit the topic since then...

> I hope that makes any sense to you (or you can figure it out from the
> testing scripts).

Thanks for posting these, though.  They do seem to be good test cases
for developing on and hopefully somebody with more interest in
this topic can pick up where we leave off.

On a side note, I have been meaning to refactor git svn and break it
apart into separate Perl modules for easier hacking for the longest time
now...

-- 
Eric Wong