1

I do my development of various features in git branches. When I want to check my code into SVN via git-svn, I do the following:

git co feature_branch
git svn rebase
git co master
git svn rebase
git merge --no-ff feature_branch
git commit --amend
git svn dcommit

This works reasonably well, unless another developer commits to SVN any time during this process, in which case either:

  • If a SVN commit is made between the time I rebase feature_branch and master, I get a log that looks like the following:

*   4e6992a BUG-003 My SVN commit (containing cdb40ba and 3b18ea4)
|\
| * cdb40ba local commit 1
| * 3b18ea4 local commit 2
* | cf8a028 BUG-002 Another developer's SVN commit
|/
* 940c613 BUG-001 Another developer's SVN commit
  • If a SVN commit is made between the time I rebase master and svn dcommit, the latter fails due to merge issues (in which case I do a hard reset and start over)

How can I accomplish this in a single atomic operation?

titaniumdecoy
  • 18,900
  • 17
  • 96
  • 133
  • What does `git amend` do? That's not a standard Git function. If you're not sure, can you give us the output of `git config --get alias.amend`? – me_and Jun 18 '12 at 08:48
  • Similar: http://stackoverflow.com/questions/10940213/git-more-efficient-way-to-do-this/10949548#10949548 – me_and Jun 18 '12 at 08:53

2 Answers2

3

I think, this problem is not solvable with git-svn because of the way SVN works (each revision creation is a separate transaction, but you can create a transaction that creates several revisions). Maybe you could solve it using SVN locks, but this approach has its shortcomings.

Pure Git pushes all your the history together as an atomic operation as you need. If you have an access to your SVN repository, you can install SubGit into it and use Git interface (pure Git interface, not git-svn) that it will create for your SVN repository.

Dmitry Pavlenko
  • 8,530
  • 3
  • 30
  • 38
0

I don't follow why you're doing your merge with --no-ff. That's always going to produce a merge commit, and my understanding of your first bullet is that you want to avoid doing that.

There's no way to always do it in a single atomic operation. In particular, your second bullet is pretty much unavoidable, although I don't think you need to go right back to the start to fix it.

Here's how I'd do it:

  1. Check out the branch containing the commits you want to push to Subversion: git checkout feature_branch.

  2. Check what I'm committing and where I'm committing it to: git svn dcommit --dry-run. I normally sanity-check the number of commits that are going to be pushed out, and verify that they're being committed to the correct Subversion branch.

  3. If I think it's likely there'll be a merge issue, git svn rebase. I normally don't bother with this, though, and only do it if I hit an error at step 4.

  4. Push the changes out: git svn dcommit. Go back to step 3 if this hits any issues.

Note I don't involve the "master" branch at all. This greatly cuts down the amount of merging I need to do, and hence the time between steps 3 and 4 where someone else's commit could get in the way of my own.

me_and
  • 15,158
  • 7
  • 59
  • 96
  • I don't want a separate SVN commit for each of my local commits which would be the result of this process. I'm looking for a way to push my changes to SVN in a single merge commit while keeping my local git history. – titaniumdecoy Jun 19 '12 at 16:48