Matthias Kleine [off-list ref] writes:
Peter Baumann wrote:
quoted
I had this situation, too.
a = svn branch 'a'
m b = svn branch 'b' (in my case, it was trunk)
/ \ m = a merge of branch 'a' and 'b', not yet commited to svn
a b
So trying to dcommit m, git svn can't figure out on which branch, as 'a'
and 'b' are both reachable. I had to use a graft file to lose one of the
parents, which let git-svn commit to SVN.
You're right, both 'a' and 'b' are reachable from 'm'. But if I got
it right 'm' also contains information as to which one is the first
parent and thereby which branch we're on. So wouldn't it be enough, if
git-svn automatically chose the first parent (using log
--first-parent)?
Parents' order and which branch you are on may not have anything
to do with each other. Somebody else may have pulled a while on
b, and you might have pulled from him the merge he created by
doing so while you are on branch a.
Junio C Hamano wrote:
Parents' order and which branch you are on may not have anything
to do with each other. Somebody else may have pulled a while on
b, and you might have pulled from him the merge he created by
doing so while you are on branch a.
You're right, I didn't think of that. While pondering this I came up
with another problem: git-svn currently remembers which svn-branch a
commit belongs to by including this information in the git commit log
message.
This way it is not possible to have one git-commit appear in more than
one svn branch. Maybe it's better to store this git-commit->svn-branch
mapping somewhere else. Although it's probably even better to completely
switch to git :)
Matthias
On Wed, Aug 08, 2007 at 08:51:55PM +0200, Matthias Kleine wrote:
Junio C Hamano wrote:
quoted
Parents' order and which branch you are on may not have anything
to do with each other. Somebody else may have pulled a while on
b, and you might have pulled from him the merge he created by
doing so while you are on branch a.
You're right, I didn't think of that. While pondering this I came up with
another problem: git-svn currently remembers which svn-branch a commit
belongs to by including this information in the git commit log message.
Thats true.
This way it is not possible to have one git-commit appear in more than one
svn branch.
But there is no way that a git commit could appear on several branches
in SVN, because SVN doesn't have the concept of multiple parents. So you
can't have a commit which describes a merge of two branches, because SVN
can't store the 2 parents. But you could have 2 commits which describe
the same state (e.g. same root tree), but are on seperate branches.
t:= commits on trunk
b:= commits on branch 'b'
repo1:
t <-trunk
|
t
| \
t b <- branch
| /
t
But this graph is only local to the committers repo. Another person
using git-svn to track the SVN repo sees this
repo2/SVN repo:
t <-trunk
|
t
|
t b <- branch
| /
t
So if you do a 'git merge trunk' in repo1 on branch 'branch', git-svn
should produce something like this:
repo2/SVN repo:
trunk-> t t' <- branch
| |
t t'
| |
t b
| /
t
The interesting case is what it will produce in *YOUR* repo. There are 2
possibilities:
repo1 (I): repo1 (II)
tb <-trunk <-branch trunk-> t b <- branch
| | |
tb t b
| \ | \|
t b <- branch t b
| / | /
t t
(I) would be nicer, but propably more difficult the way git-svn works now.
(II) would also be possible and more in line what other people importing
from SVN see.
These are the possible ways to describe the merge of 2 SVN branches.
-Peter
On Wed, Aug 08, 2007 at 09:25:37PM +0200, Peter Baumann wrote:
On Wed, Aug 08, 2007 at 08:51:55PM +0200, Matthias Kleine wrote:
quoted
Junio C Hamano wrote:
quoted
Parents' order and which branch you are on may not have anything
to do with each other. Somebody else may have pulled a while on
b, and you might have pulled from him the merge he created by
doing so while you are on branch a.
You're right, I didn't think of that. While pondering this I came up with
another problem: git-svn currently remembers which svn-branch a commit
belongs to by including this information in the git commit log message.
Thats true.
quoted
This way it is not possible to have one git-commit appear in more than one
svn branch.
But there is no way that a git commit could appear on several branches
in SVN, because SVN doesn't have the concept of multiple parents. So you
can't have a commit which describes a merge of two branches, because SVN
can't store the 2 parents. But you could have 2 commits which describe
the same state (e.g. same root tree), but are on seperate branches.
t:= commits on trunk
b:= commits on branch 'b'
repo1:
t <-trunk
|
t
| \
t b <- branch
| /
t
But this graph is only local to the committers repo. Another person
using git-svn to track the SVN repo sees this
repo2/SVN repo:
t <-trunk
|
t
|
t b <- branch
| /
t
So if you do a 'git merge trunk' in repo1 on branch 'branch', git-svn
should produce something like this:
repo2/SVN repo:
trunk-> t t' <- branch
| |
t t'
| |
t b
| /
t
The interesting case is what it will produce in *YOUR* repo. There are 2
^- should, because both cases aren't
implemented yet.
possibilities:
repo1 (I): repo1 (II)
tb <-trunk <-branch trunk-> t b <- branch
| | |
tb t b
| \ | \|
t b <- branch t b
| / | /
t t
(I) would be nicer, but propably more difficult the way git-svn works now.
(II) would also be possible and more in line what other people importing
from SVN see.
These are the possible ways to describe the merge of 2 SVN branches.
-Peter