On Fri, Sep 26, 2008 at 12:23 PM, Björn Steinbrink <B.Steinbrink@xxxxxx> 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@xxxxxxxxxxx, skype: craig.tataryn -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
