Home/ Questions/Q 3500508
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-18T12:44:33+00:00

In the company I work for, we have the policy that all code should

  • 0

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 (e.g. 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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0