Transitioned from Subversion to Git, how do I push to heroku gracefully?

Question

I had been using a Subversion for my source control, combined with git ONLY to deploy (push) to heroku. My pattern was: Update local working copy from latest master at remote subversion repository. Then do git commit and git push heroku (Git was set to ignore .svn stuff). This working copy I only used to push to heroku, I had another subversion folder for doing live development, and committing to the remote subversion repository for tracking.

I have now switched to git fully. I did a complete import from subversion into a new remote git repository. I've successfully been working on my local working copy of the git repo (origin), and pushing changes when it suits me (also collaborating with one other developer, but I basically run the operation).

MY Question:

I would now like to return to my OTHER git working copy that I had previously been using to push to heroku (that has .svn/ stuff in it as well). I'm thinking of just adding my new git repository as an [origin] entry in the .git/config.. pulling the latest changes from my new git remote, and pushing to heroku, but I'm wondering if it will freak out.

It will try and merge and get confused won't it? AND, even if the pull worked, will the heroku remote get confused about a push that originated from some new git repo?

I could clobber (delete) that working copy (used to push to heroku from subversion), and make a new clone of my new git repository, then add heroku to the .git/config. But I'm concerned pushing to heroku will still cause it to get confused, since I used to push from a different working copy.

Any advice would be great!

Thanks in advance!

Answer 1

If I understand you correctly, you want to switch back to the former SVN repository as your working copy, and you want to preserve the old SVN history?

There are a couple of options available.

1. Push the recent changes from the new Git repository to Heroku, then switch to the old repository and pull from Heroku. This will bring you old repository up to date.

2. Temporarily change the URL in the old repository's config file to point to the local path of the new repository. Pull the recent changes from there, and then revert back to the Heroku URL when done. This will also bring your old repository up to date.

The first option is the most expedient, and the second is the long way round. Either way, you will have the same net result of an up to date local repository containing all history. The surplus new repository can be disposed of in either case.

Edit: To address your concerns about whether Heroku will care about the origin of the commit, in brief, no the repository on Heroku is another git repository that accepts commits from authenticated users.

As long as the credentials are correct, the originating repository does not matter. This is the beautiful thing about DVCS - there is not one controlling or corruptible repository - It is entirely possible for you to now clone from Heroku on another machine and continue work from there. As long as your credentials are the same, the history will show any and all commits you push, but does not care where from.

If your desire is to simply use a clean repository to work with, the new one will be the favorite. The old one can be deleted without ill effects.

To prove this - check the SHA-1 hashes for a commit in both new and old repositories, and you will see they are identical. The hash is unique for all commits, and can be used to check the code integrity at all times. There will never be more than one change for any given hash.

• As a side note, the repository is portable in that it is entirely self contained, and can be moved around freely on your storage space, or even be used on external storage such as a USB thumb drive.