Reviewing local changes in Git before pushing to Subversion
The other day, I made a mistake while committing some work I'd done via Git to our SVN repository. Since this series of articles is about working with Git and SVN, I wanted to take a short time to look over what happened as well as a small change in my workflow that will prevent it from happening in the future.
The mistake was that I accidentally pushed a file I was working on to our main repository. There was no damage caused, as the file wasn't in use by anything in production yet, but I'd rather not have pushed it at all.
The solution is to diff my work against the current repository and make sure only the changes I want or going to be pushed. But since Git doesn't work in a centralized fashion, you can't run a straight diff: you first have to know which revision to use as the left hand side. In Subversion, this is straight forward as it's centralized; the left hand side is the SVN repository HEAD, and the right hand side are your uncommitted changes.
Well, with Git, it's only a tiny bit harder: all you need to know is that remote repositories have special "tracking" branches, in the Git's "remotes" branch heirarchy. When you initialized your repository with git-svn, it also created a "remotes/trunk" reference that you can use. Therefore:
% git-diff remotes/trunk ...
will show me a diff of exactly what will be committed. As I roll this into my workflow, I should be making fewer and fewer of these kinds of errors.
- bjc's blog
- Login or register to post comments