git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Help with merge and git-svn
@ 2008-09-26 16:36 Craig Tataryn
  2008-09-26 17:23 ` Björn Steinbrink
  0 siblings, 1 reply; 3+ messages in thread
From: Craig Tataryn @ 2008-09-26 16:36 UTC (permalink / raw)
  To: git

Hi, first time poster to kernel.org mailing lists, so if I commit a
taboo, please be kind to me :)

I have the following scenario:

[remote deveoper]<===>[shared git repo]<===>[me]<===>[client's svn repo]

So my remote developer and I push and pull to/from the shared git
repo, and then I sync changes to and from the client's svn repo using
git-svn.

My problem is, when I am ready to merge changes from my local master
branch to trunk-local, if I do a "git merge master" and then try to
issue any git-svn commands I get the following errors:
======================
$ git merge master
Updating d88106e..77b86ae
Fast forward
 community/pom.xml |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

$ git svn dcommit
Can't call method "full_url" on an undefined value at
/usr/local/git/libexec/git-core/git-svn line 425.

$ git svn rebase
Unable to determine upstream SVN information from working tree history
======================

The only way I've seem to be able to remedy this is if I add the
"subtree" merge strategy to the merge command:

git merge -s subtree master

Then git-svn doesn't get confused about it's repo, but when you look
at the repo using gitk, you see something like:

[trunk-local]--[remotes/trunk]  Merge branch 'master' into trunk-local
| \
|  \
|    [master]--[remotes/origin/master]  "Some commit message from the
last master commit"
|    |
|    |
|  /
/

When I use the normal merge strategy then gitk shows all branches at
the same level, but git-svn is of course b0rked.

So I guess my question is, am I stuck using "-s subtree", is this the
right course of action??  Or can I get this to work with the default
strategy?  Is this symptomatic of a messed up or disjoint history
(i.e. early on I did some --squash merges).

I have full control over the shared repo and I don't mind blowing it
away and rebuilding it based on what's in SVN if that's what it takes.

Thanks!

Craig.

-- 
Craig Tataryn
site: http://www.basementcoders.com/
podcast:http://feeds.feedburner.com/TheBasementCoders
irc: ThaDon on freenode #basementcoders, ##wicket, #papernapkin
im: craiger316@hotmail.com, skype: craig.tataryn

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Help with merge and git-svn
  2008-09-26 16:36 Help with merge and git-svn Craig Tataryn
@ 2008-09-26 17:23 ` Björn Steinbrink
  2008-09-26 18:02   ` Craig Tataryn
  0 siblings, 1 reply; 3+ messages in thread
From: Björn Steinbrink @ 2008-09-26 17:23 UTC (permalink / raw)
  To: Craig Tataryn; +Cc: git

On 2008.09.26 11:36:48 -0500, Craig Tataryn wrote:
> Hi, first time poster to kernel.org mailing lists, so if I commit a
> taboo, please be kind to me :)
> 
> I have the following scenario:
> 
> [remote deveoper]<===>[shared git repo]<===>[me]<===>[client's svn repo]
> 
> So my remote developer and I push and pull to/from the shared git
> repo, and then I sync changes to and from the client's svn repo using
> git-svn.
> 
> My problem is, when I am ready to merge changes from my local master
> branch to trunk-local, if I do a "git merge master" and then try to
> issue any git-svn commands I get the following errors:
> ======================
> $ git merge master
> Updating d88106e..77b86ae
> Fast forward
>  community/pom.xml |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> $ git svn dcommit
> Can't call method "full_url" on an undefined value at
> /usr/local/git/libexec/git-core/git-svn line 425.
> 
> $ git svn rebase
> Unable to determine upstream SVN information from working tree history
> ======================
> 
> The only way I've seem to be able to remedy this is if I add the
> "subtree" merge strategy to the merge command:
> 
> git merge -s subtree master
> 
> Then git-svn doesn't get confused about it's repo, but when you look
> at the repo using gitk, you see something like:
> 
> [trunk-local]--[remotes/trunk]  Merge branch 'master' into trunk-local
> | \
> |  \
> |    [master]--[remotes/origin/master]  "Some commit message from the
> last master commit"
> |    |
> |    |
> |  /
> /
> 
> When I use the normal merge strategy then gitk shows all branches at
> the same level, but git-svn is of course b0rked.
> 
> So I guess my question is, am I stuck using "-s subtree", is this the
> right course of action??  Or can I get this to work with the default
> strategy?  Is this symptomatic of a messed up or disjoint history
> (i.e. early on I did some --squash merges).
> 
> I have full control over the shared repo and I don't mind blowing it
> away and rebuilding it based on what's in SVN if that's what it takes.

The original merge you did ended up as a fast-forward, ie. no merge
commit was created. I guess that your history is so, that somehow the
remotes/trunk stuff is reachable through the second parent of some merge
commit that exists in your history. But git-svn uses --first-parent to
find its upstream, so it cannot find that in your scenario. I guess it's
best if you use "git merge --no-ff master" to force the creation of a
merge commit. Subtree happens to work because it implies --no-ff, but
I'm not sure whether there might be downsides to using the subtree
strategy, so I'd rather go with the explicit --no-ff and the normal
merge strategies.

Björn

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Help with merge and git-svn
  2008-09-26 17:23 ` Björn Steinbrink
@ 2008-09-26 18:02   ` Craig Tataryn
  0 siblings, 0 replies; 3+ messages in thread
From: Craig Tataryn @ 2008-09-26 18:02 UTC (permalink / raw)
  To: git

On Fri, Sep 26, 2008 at 12:23 PM, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> On 2008.09.26 11:36:48 -0500, Craig Tataryn wrote:
>> Hi, first time poster to kernel.org mailing lists, so if I commit a
>> taboo, please be kind to me :)
>>
>> I have the following scenario:
>>
>> [remote deveoper]<===>[shared git repo]<===>[me]<===>[client's svn repo]
>>
>> So my remote developer and I push and pull to/from the shared git
>> repo, and then I sync changes to and from the client's svn repo using
>> git-svn.
>>
>> My problem is, when I am ready to merge changes from my local master
>> branch to trunk-local, if I do a "git merge master" and then try to
>> issue any git-svn commands I get the following errors:
>> ======================
>> $ git merge master
>> Updating d88106e..77b86ae
>> Fast forward
>>  community/pom.xml |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> $ git svn dcommit
>> Can't call method "full_url" on an undefined value at
>> /usr/local/git/libexec/git-core/git-svn line 425.
>>
>> $ git svn rebase
>> Unable to determine upstream SVN information from working tree history
>> ======================
>>
>> The only way I've seem to be able to remedy this is if I add the
>> "subtree" merge strategy to the merge command:
>>
>> git merge -s subtree master
>>
>> Then git-svn doesn't get confused about it's repo, but when you look
>> at the repo using gitk, you see something like:
>>
>> [trunk-local]--[remotes/trunk]  Merge branch 'master' into trunk-local
>> | \
>> |  \
>> |    [master]--[remotes/origin/master]  "Some commit message from the
>> last master commit"
>> |    |
>> |    |
>> |  /
>> /
>>
>> When I use the normal merge strategy then gitk shows all branches at
>> the same level, but git-svn is of course b0rked.
>>
>> So I guess my question is, am I stuck using "-s subtree", is this the
>> right course of action??  Or can I get this to work with the default
>> strategy?  Is this symptomatic of a messed up or disjoint history
>> (i.e. early on I did some --squash merges).
>>
>> I have full control over the shared repo and I don't mind blowing it
>> away and rebuilding it based on what's in SVN if that's what it takes.
>
> The original merge you did ended up as a fast-forward, ie. no merge
> commit was created. I guess that your history is so, that somehow the
> remotes/trunk stuff is reachable through the second parent of some merge
> commit that exists in your history. But git-svn uses --first-parent to
> find its upstream, so it cannot find that in your scenario. I guess it's
> best if you use "git merge --no-ff master" to force the creation of a
> merge commit. Subtree happens to work because it implies --no-ff, but
> I'm not sure whether there might be downsides to using the subtree
> strategy, so I'd rather go with the explicit --no-ff and the normal
> merge strategies.
>
> Björn
>

Thanks for this tip Bjorn, I'll give it a shot.

-- 
Craig Tataryn
site: http://www.basementcoders.com/
podcast:http://feeds.feedburner.com/TheBasementCoders
irc: ThaDon on freenode #basementcoders, ##wicket, #papernapkin
im: craiger316@hotmail.com, skype: craig.tataryn

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2008-09-26 18:03 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-09-26 16:36 Help with merge and git-svn Craig Tataryn
2008-09-26 17:23 ` Björn Steinbrink
2008-09-26 18:02   ` Craig Tataryn

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).