Re: Help with merge and git-svn

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