On Oct 1, 2007, at 4:50 AM, Bj=F6rn Steinbrink wrote:
quoted text > On 2007.09.30 16:15:49 +0200, Benoit SIGOURE wrote:
>> On Sep 30, 2007, at 1:05 PM, Bj=F6rn Steinbrink wrote:
>>
>>> Hi,
>>>
>>> I recently discovered git-svn and absolutey love it. One thing =20
>>> that I'm
>>> missing though, is an equivalent of "svn merge" for merging =20
>>> between svn
>>> remotes, to support the SVN way of using "squashed" merges, where =20=
quoted text >>> you
>>> just note the merge meta-data in the commit message. "git merge" =20
>>> didn't
>>> work for me (and probably isn't expected to work) to merge =20
>>> between two
>>> svn branches, so I've resorted to cherry-picking the required =20
>>> commits
>>> one by one into a temporary branch and then squashing them =20
>>> together by
>>> doing a --squash merge with a second temporary branch (as in [1]).
>>
>> I fail to see why you'd want to reproduce the broken behavior of =20
>> svn merge.
>> Anyways, git-svn is a great way to merge SVN branches, =20
>> unfortunately it
>> can't detect when merges happened on the SVN side. I think you =20
>> can use it
>> nevertheless by manually adding a graft at the last merge point, =20
>> which
>> would help you merging the right revisions without having to =20
>> specify what
>> needs to be merged (unless someone made another merge on the SVN =20
>> side, in
>> which case you need to update your graft).
>
> Then how does that work? The manpage explicitly says that I should not
> use git-{pull,merge} on branches I want to dcommit from. And a trivial
> test immediately got the expected effect of git-svn trying to =20
> commit to
> trunk instead of the branch.
Ah, yes, you're right. Well, this will work the day we can pass an =20
option to git-svn dcommit to tell it where the commit must be sent.
--=20
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
