From: Benoit SIGOURE Date: Mon, 01 Oct 2007 07:56:21 GMT Subject: Re: git-svn merge helper Message-ID: <0D8A7A3C-8F51-482D-9229-29ADC9585760@lrde.epita.fr> In-Reply-To: <20071001025059.GA29323@atjola.homenet> On Oct 1, 2007, at 4:50 AM, Björn Steinbrink wrote: > On 2007.09.30 16:15:49 +0200, Benoit SIGOURE wrote: >> On Sep 30, 2007, at 1:05 PM, Björn Steinbrink wrote: >> >>> Hi, >>> >>> I recently discovered git-svn and absolutey love it. One thing >>> that I'm >>> missing though, is an equivalent of "svn merge" for merging >>> between svn >>> remotes, to support the SVN way of using "squashed" merges, where >>> you >>> just note the merge meta-data in the commit message. "git merge" >>> didn't >>> work for me (and probably isn't expected to work) to merge >>> between two >>> svn branches, so I've resorted to cherry-picking the required >>> commits >>> one by one into a temporary branch and then squashing them >>> 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 >> svn merge. >> Anyways, git-svn is a great way to merge SVN branches, >> unfortunately it >> can't detect when merges happened on the SVN side. I think you >> can use it >> nevertheless by manually adding a graft at the last merge point, >> which >> would help you merging the right revisions without having to >> specify what >> needs to be merged (unless someone made another merge on the SVN >> 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 > commit to > trunk instead of the branch. Ah, yes, you're right. Well, this will work the day we can pass an option to git-svn dcommit to tell it where the commit must be sent. -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory