git-svn: Finding the svn-URL of the current branch in git

> Hi there,
>
> when running "git-svn dcommit" git-svn tries to find the svn-URL of the 
> current branch int git by looking for the most recent git log-entry 
> corresponding to a commit in svn (see working_head_info in git-svn).  In 
> case a merge just happended this might be the URL of another branch. Would 
> using "log --first-parent" instead of a plain "log" take care of this 
> problem or would it have other undesirable consequences?
>

> 
> 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.

> Peter Baumann wrote:
>>
>> 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.

> On Wed, Aug 08, 2007 at 08:51:55PM +0200, Matthias Kleine wrote:
> > 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.
> 
> 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.
> 

> On Tue, Aug 07, 2007 at 08:29:23PM +0200, Matthias Kleine wrote:
> > Hi there,
> >
> > when running "git-svn dcommit" git-svn tries to find the svn-URL of the 
> > current branch int git by looking for the most recent git log-entry 
> > corresponding to a commit in svn (see working_head_info in git-svn).  In 
> > case a merge just happended this might be the URL of another branch. Would 
> > using "log --first-parent" instead of a plain "log" take care of this 
> > problem or would it have other undesirable consequences?
> >
> 
> 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.
> 
> So for a short fix to get the work done, you could create a graft file
> where you fake m to only have one parent.

> Peter Baumann <waste.manager@gmx.de> wrote:
> > On Tue, Aug 07, 2007 at 08:29:23PM +0200, Matthias Kleine wrote:
> > > Hi there,
> > >
> > > when running "git-svn dcommit" git-svn tries to find the svn-URL of the 
> > > current branch int git by looking for the most recent git log-entry 
> > > corresponding to a commit in svn (see working_head_info in git-svn).  In 
> > > case a merge just happended this might be the URL of another branch. Would 
> > > using "log --first-parent" instead of a plain "log" take care of this 
> > > problem or would it have other undesirable consequences?
> > >
> > 
> > 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.
> > 
> > So for a short fix to get the work done, you could create a graft file
> > where you fake m to only have one parent.
> 
> Ok.  I'm regretting making 733a65aa5d33196fac708ebd12a98a1060cbf3c2 now.
> 
> It doesn't introduce the problem, but it does encourage it.  I still
> happen to believe allowing git-merges in repositories that try to
> interoperate with SVN is just giving rope for users to hang themselves
> with.
> 
> 
> Junio:
> Would you object to having git-merge spew a big fat warning
> and/or outright refuse to let git-merge run on git-svn repositories?
> 

> 
> 13c823fb520eaf1cded520213cf0ae4c3268208d was introduced to allow using
> git-format-patch + git-am to apply patches from other branches in SVN,
> which is the recommended way to do "merging" with git-svn.
> 

> On Thu, Aug 16, 2007 at 01:21:10AM -0700, Eric Wong wrote:
> > Peter Baumann <waste.manager@gmx.de> wrote:
> > > On Tue, Aug 07, 2007 at 08:29:23PM +0200, Matthias Kleine wrote:
> > > > Hi there,
> > > >
> > > > when running "git-svn dcommit" git-svn tries to find the svn-URL of the 
> > > > current branch int git by looking for the most recent git log-entry 
> > > > corresponding to a commit in svn (see working_head_info in git-svn).  In 
> > > > case a merge just happended this might be the URL of another branch. Would 
> > > > using "log --first-parent" instead of a plain "log" take care of this 
> > > > problem or would it have other undesirable consequences?
> > > >
> > > 
> > > 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.
> > > 
> > > So for a short fix to get the work done, you could create a graft file
> > > where you fake m to only have one parent.
> > 
> > Ok.  I'm regretting making 733a65aa5d33196fac708ebd12a98a1060cbf3c2 now.
> > 
> > It doesn't introduce the problem, but it does encourage it.  I still
> > happen to believe allowing git-merges in repositories that try to
> > interoperate with SVN is just giving rope for users to hang themselves
> > with.
> > 
> > 
> > Junio:
> > Would you object to having git-merge spew a big fat warning
> > and/or outright refuse to let git-merge run on git-svn repositories?
> 
> By removing merges in git-svn, it would lose much of its 'magic'. I have
> to mainain a SVN branch and from time to time, I merge with trunk. So
> it'll totally screw me if I lose the merge history (sure, I could use
> a graft file, but a real merge is preferable, because I can clone the
> repo then).

> > 13c823fb520eaf1cded520213cf0ae4c3268208d was introduced to allow using
> > git-format-patch + git-am to apply patches from other branches in SVN,
> > which is the recommended way to do "merging" with git-svn.
> > 
> Hm. What about cherry pick? I ask because a friend of mine messed up the
> SVN repo after cherry picking a commit from 'trunk' and then his next
> dcommit put everything into 'trunk' instead of his own branch (hopefully,
> I remembered correctly; but at least I know for sure a cherry pick from
> trunk was involved). I can't ask him right now, because he is on
> vacation till monday, but I'll Cc him, just in case.

> Eric Wong <normalperson@yhbt.net> writes:
> 
> > Junio:
> > Would you object to having git-merge spew a big fat warning
> > and/or outright refuse to let git-merge run on git-svn repositories?
> 
> Actually I do.  A major, if not primary, selling point of
> git-svn has been that svn cannot do merges but if you import to
> git you can, and I've had an impression that Sam's git-svn intro
> alludes to this capability as well.

> If I understand you correctly, your position is that the svn
> side has the authoritative history when using git-svn, and we
> should refuse to do anything on the git side that the resulting
> history in svn cannot represent.  I know and respect that you
> have thought about the issues involved long enough before that
> declaration of defeat, but at the same time, I would really hope
> that we can come up with a workable compromise to allow merge
> tracking on the git side.

> It probably does not even have to interoperate with people who
> do their own merge tracking using svk.  Perhaps something as
> simple and ugly as recording the parent commit object names on
> the git side as a trailer to the commit log message we push back
> to svn would allow people who interact with the same svn
> repository from their own git-svn managed git repository to
> interoperate with each other?

> Junio C Hamano <gitster@pobox.com> wrote:
>
>> Actually I do.  A major, if not primary, selling point of
>> git-svn has been that svn cannot do merges but if you import to
>> git you can, and I've had an impression that Sam's git-svn intro
>> alludes to this capability as well.
>
> Wow.  My primary reasons for git-svn are completely different: speed
> and offline usability; and merging was not so much a concern for me.
>
>> If I understand you correctly, your position is that the svn side
>> has the authoritative history when using git-svn, and we should
>> refuse to do anything on the git side that the resulting history in
>> svn cannot represent.  I know and respect that you have thought
>> about the issues involved long enough before that declaration of
>> defeat, but at the same time, I would really hope that we can come
>> up with a workable compromise to allow merge tracking on the git
>> side.
>
> Yes.  From what I gather, developers only use git-svn because they
> don't have enough swing within their group to replace SVN.

> David Kastrup <dak@gnu.org> writes:
>
> > git-svn makes it possible for me to keep the mess that is git to
> > myself, and only expose others to the _results_ of my work with
> > it.
>
> Very well put. It is not just svn but I privately use git on top of
> cvs managed project for exactly this reason.