Maintain set of local commits working with git-svn

Question

I am using git to develop against a project hosted in subversion, using git-svn:

git svn clone svn://project/

My general workflow has been to repeatedly edit-and-commit on the master branch, then commit to the svn repository via:

git stash
git svn dcommit
git stash apply

One of the local modifications that 'stash' command is preserving, that I don't want to commit to the svn repository, is a changed database connection string. What's the most convenient way to keep this local change without the extra 'stash' steps?

I suspect that something like 'stash' or 'quilt' is what I'm looking for, but I'm still new enough to git that I think I'm missing some terminology that would lead to the exact incantation.

Update: The only solution I found that seems to avoid the git stash + git-svn action + git stash apply series was to update the git-svn ref manually:

(check in local-only change to 'master', then...)
$ cat .git/refs/master > .git/refs/remote/git-svn
$ git svn fetch (with at least one new SVN revision)

And that leaves the local-only commit as a weird (probably unsafe) commit between two svn revisions.

Answer 1

Not exactly a git answer to your question, but useful nonetheless:

It is a standard practice in the django circles to include the database connections etc in a local file that is not in the repository, called localsettings.py

This file is unique to each environment you deploy in; It helps to include an example file with the repo, say, localsettings.py.example

Otherwise, include all repos' config files and implement infrastructure to query the appropriate ones based on the host name.

Answer 2

I use stg (which is quilt but integrated with git) alongside git svn.

I have patches in stg that patch the build system in a way that I don't want to send upstream - so thats like your DB patch.

To apply patches:

stg pop -a stg push patch-name-that-i-want-to-apply git svn dcommit

or to rebase against latest SVN:

git svn fetch stg rebase trunk (or whatever your svn branch is called)

Answer 3

One possible approach is to have a "local" branch with the local-only modifications, and branch a "work" branch from it. In this setup you can:

git checkout work
git checkout -b work_tmp
git rebase --onto master local work_tmp
git checkout master
git merge work_tmp
git branch -D work_tmp
git svn dcommit master

(and create a shell script for it, naturally)

I just started using this on a project and there may be drawbacks to this method.

Answer 4

I must agree that the real solution is not to commit stuff that doesn't belong in the repository. I'd go to the guy you're trying to convince and tell him that you want to add a mechanism where you can override the default properties with a file you add on your local system.

There is no clean way to solve the merge conflicts that might occur when the property is renamed for example. So I think you're looking at a hack for a poorly implemented solution and that is why no direct answer to your question is going to seem unhackish.