git svn dcommit without rebasing

Our company uses (and supports!) SVN, but I tend to use git. What I want to try is to have git repository – one per project, project developers will be able to pull from this repository (and of course pull from each other if they will want to). But I still want to push all the changes to the SVN, because SVN is being maintained by our tech-support.

I was testing the scenario with following repositories:

  • Git revert on published commits while maintaining ability to merge in future?
  • .gitignore not working after adding it to already modified repo.
  • Git submodules removing on checkout another branch
  • Git history rewrite on Bitbucket HEAD -> branch (pre-receive hook declined)
  • squash commits after rebasing
  • Git: is there a quicker way to merge from one branch to multiple branches than doing each one serially?
    1. SVN-repository – this one is maintained by our company and our team should push all changes there at some point
    2. git-svn-clone – this is git repository cloned from SVN above – all project developers should push their commits here
    3. git-dev-clone – this is developer’s git repository.

    The only issue with straightforward usage of ‘git svn rebase‘ and ‘git svn dcommit’ that I’ve noticed is that after each push from developer’s git repository to the git-svn-clone repository I have to rebase developer’s repository as soon as changes will be propagated to SVN and rebased. What I want to achieve is to avoid rebasing after each push.

    Please note that I’m assuming that every project developer will use only git repository and nobody will use SVN directly.

    I was able to achieve this behavior manually by checking out every git commit one by one in ‘git-svn-clone’ repository after push and committing those changes to the SVN using SVN client. I believe that ‘git svn dcommit’ does the same but it also syncs back from SVN and changes commit SHA identifiers which forces me to rebase.

    P.S.: --no-rebase option for git svn dcommit didn’t help since after first commit propagated to SVN git svn dcommit didn’t allow me committing more changes to the SVN until previous one was rebased. I’ve tried this behavior once and probably could overlook something.

  • Where is the list of recently checked out references stored, such as those used by `git checkout -`
  • git svn dcommit with svn usernames
  • Prevent other git authors
  • Mount git branches in a container
  • git svn fetch & rebase broken after connection failure
  • Using OS X FileMerge/opendiff to view git differences, loading all files at once in the directory view
  • One Solution collect form web for “git svn dcommit without rebasing”

    It’s actually even worse than that… dcommit changes the commits uploaded to SVN (adding git-svn-id lines, changing the authorship information, etc.) even if you hacked dcommit to not try to rebase.

    Basically, git-svn is not able to sync back from SVN ever without doing rebases. A new git<->SVN interface that might remove this limitation is being worked on, but it’s not ready yet.

    I’m afraid that if you want to keep in sync with the SVN repository, your scenario will not work without rebasing right now.

    Git Baby is a git and github fan, let's start git clone.