Git users in an SVN shop, organising our repos

I work in an SVN shop, but to inject a bit of sanity in my work I use git-svn. A growing number of my colleagues are seeing the light as well, and now we’d like to, in some cases completely side-step SVN. Currently we each have our own git-svn repo, but due to wildly differing hashes we can’t really share anything except plain patches or via SVN. How should we organise our repos in order to allow direct sharing (via git-remote)?

The only way I can come up with is a single, shared git-svn repo, which we use as a gateway to SVN, but that’d probably be a bit cumbersome to work with–it’d be much better if we all could push to SVN directly from our own git-svn repos.

  • git and CR vs LF (but NOT CRLF)
  • Git fails to clone repo from ownCloud's webdav interface
  • How do I split a branch after a certain commit?
  • How can I find all the merges that had conflicts in a Git repository?
  • Cannot push to remote git repository
  • Switching users inside Docker image to a non-root user
  • Edit: Unfortunately I don’t have admin access to the SVN server, so solutions like subgit are of little use at the moment, even though they are of interest.

  • Can I load one .gitconfig file from another?
  • How to connect to a remote GIT repository?
  • How to pragmatically check with bash script if a branch in git needs to be rebased?
  • Why doesn't git pull bring back directories that I've deleted?
  • use hooks in git to import and export to cvs
  • Git hash search engine
  • 5 Solutions collect form web for “Git users in an SVN shop, organising our repos”

    You may look at subgit:

    SubGit is tool for a smooth, stress-free Svn to Git migration. Install it once on the server side and use both Subversion and Git as long as you like.

    SubGit lets one to set up a bidirectional Subversion to Git replication (writable mirror).

    And:

    SubGit is a solution for a company-wide migration from Svn to Git that is:

    Much better than git-svn (see comparison);
    Requires no changes of the infrastructure that is already in place;
    Allows one to use all Git and all Subversion features;
    Provides genuine stress-free migration experience.
    

    Bidirectional gatewaying between two different version control systems predates git by ages. I have already been doing it by hand between CVS and Arch some 10 years ago. If you don’t want to buy subgit, you can maintain the gateway manually or even try to script it. The workflow is simple:

    • Have two branches, trunk and master. trunk mirrors subversion, master is plus the changes developed in git
    • Whenever there is new change in subversion:
      1. $ git svn fetch
      2. master$ git merge trunk
    • Whenever trunk is pushed:
      1. trunk$ git merge master
      2. trunk$ git svn dcommit
      3. master$ git merge trunk
    • You should do both sequences atomically, i.e. only one operation at a time.
    • You may consider setting git-svn up so it does not rewrite the commits with the subversion revision info to reduce the number of merge commits in git.
    • It can be done for multiple branches, but I don’t think merging separate subversion branches in git could work.

    We are in exactly the same situation. What we have is (warning, some pseudo-code!):

    • remote git repo, scripted (using bash scripts), cannot be –bare
    • a pre-receive hook that checks the username, then per each ref received and for all SVN-mapped branches: (git -> svn):

      • git checkout -f <branch>
      • git reset HEAD --hard
      • git clean -fdx
      • git merge -n $newrev
      • git svn dcommit
      • if failed, revert all,

      • then, after all loops – update all SVN branches (using the script, see below)

    • a cronjob updating git-svn branches with latest svn changes (svn -> git):

      • git checkout --orphan svn-update <random-branch-name>
      • git svn fetch --all
      • for all git-svn branches: git branch -D <branch> && git branch --track <svn-branch> refs/remotes/<svn-branch>,
    • ssh keys for git authentication

    • users-managed SVN authentication (based on git usernames, this will depend on your setup)

    This way no one uses SVN directly and the only difference vs pure git is you cannot change git-svn branches history (as SVN will not let you dcommit that).

    it’d be much better if we all could push to SVN directly from our own git-svn repos.

    Isn’t the what git svn dcommit command is for?

    Use git svn rebase to rebase your git clone to the central svn repo, then git svn dcommit to push your local commits to svn.

    I use git svn every day with the GCC git mirror and it works very well. Maybe that’s because there’s a central read-only mirror, that gets updated automatically from svn commits, so everyone using git-svn sees the same history from the git mirror and the same set of commit-ids. That allows fetching and merging from the read-only mirror, then just to a git svn rebase and git svn dcommit to push changes to the svn repo. Those changes then get sync’d to the read-only mirror and fetched by everyone else, with the same IDs.

    I’m in a similar setup, and here’s a process that worked for me and the folk I work with:

    1. One person creates a Git repository using git svn clone and friends.

    2. Everyone else clones that first Git repository using regular Git commands, then copies the svn-remote.{name} bits of the first repository’s .git/config. There’s instructions for doing this in the examples in git help svn.

    Now, everyone has a git-svn setup that can be used to interact with the Subversion repository.

    More importantly, everyone has a git-svn setup with the same branches and commit history, which means the commits that git svn fetch and friends create will be identical, including the hashes. At that point, as well as pushing and pulling to the Subversion repository, you can use all Git’s fancier distributed features amongst yourselves.

    Unlike with regular Git, you do need to be careful about sharing config – if your branch structure diverges, your hashes will diverge too. Occasionally things will go wrong and need fixing up (I once had two git svn fetches going on at once, which clobbered each others work in a subtle way; I had to rewind my history with git svn reset and refetch in order to keep my hashes matching other people’s). But them’s the restrictions of mashing the two tools together.

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