From: Matthias Kleine <hidden> Date: 2016-06-15 22:43:28
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
From: Peter Baumann <hidden> Date: 2016-06-15 22:43:28
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
From: Matthias Kleine <hidden> Date: 2016-06-15 22:43:28
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
From: Eric Wong <hidden> Date: 2016-06-15 22:43:29
Peter Baumann [off-list ref] wrote:
On Tue, Aug 07, 2007 at 08:29:23PM +0200, Matthias Kleine wrote:
quoted
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.
From: Peter Baumann <hidden> Date: 2016-06-15 22:43:29
On Thu, Aug 16, 2007 at 01:21:10AM -0700, Eric Wong wrote:
Peter Baumann [off-list ref] wrote:
quoted
On Tue, Aug 07, 2007 at 08:29:23PM +0200, Matthias Kleine wrote:
quoted
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
From: Eric Wong <hidden> Date: 2016-06-15 22:43:29
Peter Baumann [off-list ref] wrote:
On Thu, Aug 16, 2007 at 01:21:10AM -0700, Eric Wong wrote:
quoted
Peter Baumann [off-list ref] wrote:
quoted
On Tue, Aug 07, 2007 at 08:29:23PM +0200, Matthias Kleine wrote:
quoted
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.
quoted
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