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