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

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

[Matthias Kleine]

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?

Regards,
Matthias Kleine

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

[Peter Baumann]

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.

On the longer run, I would make sense to have an option to explicitly
specify on which SVN branch 'git-svn dcommit' should operate.

-Peter

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

[Matthias Kleine]

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)?

> 
> 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.
>
Thanks for that one. I didn't know about the grafts file before.

Matthias

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

[Junio C Hamano]

Matthias Kleine <matthias_kleine@gmx.de> writes:

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

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

[Matthias Kleine]

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

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

[Peter Baumann]

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.

-Peter

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

[Peter Baumann]

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:
> > 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
                                  ^- 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

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

[Eric Wong]

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 the longer run, I would make sense to have an option to explicitly
> specify on which SVN branch 'git-svn dcommit' should operate.

Patches welcome :)

-- 
Eric Wong

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

[Peter Baumann]

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.

-Peter

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

[Eric Wong]

Peter Baumann <waste.manager@gmx.de> wrote:
> 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).

Ok, outright refusing to merge/pull is probably too much.  But spewing
a big warning may help.

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

Yeah, cherry-pick works, too.  I've never actually used cherry-pick
myself, because git-format-patch and git-am let me work on a series of
patches rather than one-at-a-time.

-- 
Eric Wong

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

[Junio C Hamano]

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?

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

[Eric Wong]

Junio C Hamano <gitster@pobox.com> wrote:
> 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.

Wow.  My primary reasons for git-svn are completely different: speed and
offline usability; and merging was not so much a concern for me.

I've grown to prefer the patch + rebase model of keeping history linear
in my work.  This is different than from when I first picked up git:
went overboard on merging just to see what kind of interesting graphs I
could create in gitk :)

So I didn't always prefer the recommended way git-svn works now.  In the
beginning there was the "git-svn commit" command, which has now been
named "set-tree".  I haven't used set-tree in ages, but I think it still
supports preserving history of a git <-> git merging after commiting to
SVN.  The problem with set-tree was that it would either:

a) make history ugly (with duplicate commits) for git users, as history
   never gets rewritten when using set-tree.

or

b) hide history from SVN users.

> 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.  I don't think
encouraging git-svn users to isolate themselves with their own history
and propagating less-useful history to the non-SVN users in a project is
a good thing.

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

Of course, git-svn has gotten a lot more users than I expected it
would, so maybe I'll implement it and see where it takes us.

This could just be as simple as using the code for set-tree and instead
using it to create revprops in SVN.  I'd probably be inventing a fourth
method of doing merge-tracking in SVN, though...

-- 
Eric Wong

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

[David Kastrup]

Eric Wong <normalperson@yhbt.net> writes:

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

Not at all.  Subversion has _working_ subproject support (which is
rather easy, since every directory is treated the same and you can
merge at every level).  It also has other tools like "Trac".  And it
provides a _stable_ history and point of reference and backup.  While
I appreciate being able to create and undo almost any mess in my
personal git repository (and this happens not infrequently), I would
not want to propose that to everybody.

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.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Junio C Hamano]

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.

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

[Karl Hasselström]

On 2007-08-18 03:04:20 -0700, Junio C Hamano wrote:

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

I use git (and git-svn, and StGIT) on top of our Subversion repository
at work for this reason too: git lets me rewrite recent history until
it's pretty, while svn considers history totally immutable (barring a
dump+filter+reload of the whole (central) repository).

However, I object to the insinuation (in David's post, if not yours)
that "history in git is a mess" because it's mutable. git lets you set
the policy for each of your branches: either allow history editing (to
be able to fix embarrassing mistakes), or don't (to let people rely on
history to not change under their feet). This is strictly better than
Subversion, which forces you to adopt the latter policy.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle