0

EDIT: I see that this question has been asked before! git-svn: reset tracking for master Someone with the right permissions can probably close this as a duplicate.

I'm using git-svn. I recently finished working on a branch in git that was tracking a branch in SVN. While working in the branch, I was using the following two commands 

$ git svn rebase
$ big svn dcommit

and all was well. "master" in git was tracking svn/trunk and "myBranch" in git was tracking svn/branches/myBranch. But after I merged everything locally in git

$ git checkout master
$ git merge myBranch

I went to push ... and assumed that master would push to svn/trunk. But it didn't. Instead, "master" now ALSO pushes to svn/branches/myBranch. Somehow, when I merged "myBranch" into "master", "master's" tracking got altered.

I am probably doing this wrong - but I tried to explicitly "push" to trunk ... 

$ git svn dcommit remotes/trunk master

But that syntax failed and now I've got

$ Committing to http://<repo>/trunk ...
dcommitted on a detached HEAD because you gave a revision argument.
The rewritten commit is: b461234...

with SVN trunk still not updated.

How do I merge in git and then push that to SVN? I was following the guide here which implies that I can merge with normal git syntax. It just doesn't follow up and explain why my "master" is not tracking the branch I merge in.

I also have git-tower which I use in parallel with the command line and after I manually merged as above, tower now "shows" all the remote branches in the drop down to "push" or dcommit to, but I can't change the selection from svn/myBranch ... which possibly implies that I can't?

Community
  • 1
  • 1
Luther Baker
  • 7,236
  • 13
  • 46
  • 64

2 Answers2

0

If master is tracking your svn remote, you can just do:

git svn dcommit

While you're on master. Use --dry-run to see where your commit is headed to be sure! If it's broken, you can edit .git/config and fix up your svn-remote entry:

[svn-remote "svn"]
     url = svn+ssh://some.machine.net/svn/path/to/tree
     fetch = trunk:refs/remotes/trunk

Or whatever it needs to be.

Carl Norum
  • 219,201
  • 40
  • 422
  • 469
0

No, you can't commit git merges to Subversion.

Read this paragraph about branching issues with git svn from the link you gave:

When you’ve become comfortable with a Git workflow, you’ll likely create topic branches, do work on them, and then merge them in. If you’re pushing to a Subversion server via git svn, you may want to rebase your work onto a single branch each time instead of merging branches together. The reason to prefer rebasing is that Subversion has a linear history and doesn’t deal with merges like Git does, so git svn follows only the first parent when converting the snapshots into Subversion commits.

Running dcommit on a branch with merged history works fine, except that when you look at your Git project history, it hasn’t rewritten either of the commits you made on the experiment branch — instead, all those changes appear in the SVN version of the single merge commit.

When someone else clones that work, all they see is the merge commit with all the work squashed into it; they don’t see the commit data about where it came from or when it was committed.

knittl
  • 246,190
  • 53
  • 318
  • 364
  • As per the link I included, I guess the following was misleading since, although limited, I think the text implies that it will still work .... Now, if you want to merge your opera branch into trunk (your master branch), you can do so with a normal git merge. But you need to provide a descriptive commit message (via -m), or the merge will say “Merge branch opera” instead of something useful. – Luther Baker Feb 09 '12 at 18:45
  • Remember that although you’re using git merge to do this operation, and the merge likely will be much easier than it would be in Subversion (because Git will automatically detect the appropriate merge base for you), this isn’t a normal Git merge commit. You have to push this data back to a Subversion server that can’t handle a commit that tracks more than one parent; so, after you push it up, it will look like a single commit that squashed in all the work of another branch under a single commit. – Luther Baker Feb 09 '12 at 18:45