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 bydoing 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, inwhich 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 trivialtest immediately got the expected effect of git-svn trying to commit totrunk 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
Attachment:
PGP.sig
Description: This is a digitally signed message part
