How to use git-svn as intermediate review tool for a SVN repository?

Question

In the company I work for, we have the policy that all code should be reviewed before it is checked in into the SVN repository. Normally, before I commit, I just ask a collegue to review, but at this moment there is nobody around for a couple of days, and I have several tasks to do with the same class.

I installed git, and used git-svn to make a local repository. I committed every change I am going to propose after some time, and with git-svn dcommit , I can sync my stuff inside the master repository.

The question now is: what happens if my co-worker that will review my stuff in a few days disagrees with one commit, or wants me to make some additional changes (eg code comments)? How do I do that without having to do an extra commit, that will eventually show up in my SVN master repository?

Example, let's say - for the sake of understandibility - that I am working on one file.

• SVN fetched rev 1000
• Added code change A, git commit.
• Added code change B, git commit.
• Added code change C, git commit.

Now, my co-worker accepts changes A and C, but disagrees with change B, and wants more comments to go in along with change B. The result I want to end up with eventually is:

• SVN rev 1001 - Code change A
• SVN rev 1002 - Modified code change B + addtitional comments
• SVN rev 1003 - Code change C.

I am not very familiar with git , and am quite familiar with SVN. How do I change the contributions I committed into code change B without making a fourth commit?

Answer 1

Just create a branch and do commits on that branch. Let your coworker late review the code and then merge the code back to trunk (eg) or to an other branch.

Answer 2

The key is not to push your changes into svn until they are approved. Once you have run git svn dcommit , you lose the git's power to edit and reorder your commits. dcommit makes your changes public, and svn's history is (for the most part) immutable.

I usually make my changes in a branch and push them to a public git repository whose location I give to my code reviewers. I can then keep working on another project in a separate branch. Based on the feedback from the review, I can make changes to the branch in my working repository and republish for review, and when everything is ready, I do a final git svn dcommit to finalize my changes into svn.

Answer 3

First off, you shouldn't need an additional VCS to perform code reviews at your company before committing to trunk . khmarbaise's answer is the right one. The proper (and sane) way to do this is to create a branch , make your changes in the branch, have your colleague check out that branch when you're done, review the code, commit remedial changes your branch, and then whoever has authority will merge your branch into trunk . This is basic VCS protocol. If this is not the way your company does it, it's a sure sign your company's Doing It Wrong when it comes to VCS.

If you absolutely must use an external tool because your company policy is inane, then to to address the following part of your question

Example, let's say - for the sake of understandibility - that I am working on one file.

• SVN fetched rev 1000
• Added code change A, git commit.
• Added code change B, git commit.
• Added code change C, git commit.

Now, my co-worker accepts changes A and C, but disagrees with change B, and wants more comments to go in along with change B. The result I want to end up with eventually is:

• SVN rev 1001 - Code change A
• SVN rev 1002 - Modified code change B + addtitional comments
• SVN rev 1003 - Code change C.

I am not very familiar with git, and am quite familiar with SVN. How do I change the contributions I committed into code change B without making a fourth commit?

I don't even understand why you would want to avoid a fourth commit in the first place, if you're allowed to make three commits that affect one feature.

If you really, really are intent on going through with this whole idea, then yes, you can do it, and to do so, you would need to very carefully use git rebase --interactive . This powerful command can allow you to go back through your commits and completely alter the changes made in each one. I must emphasize that this has high potential for loss of work (or at least cost you significant time in recovery), and should only be done if you have a very firm knowledge of git itself.

But you really, really should be using SVN branching and merging to do all of this.