views:

93

answers:

4

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.

A: 

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.

Lakshman Prasad
Just the other day, I said to the lead developer on the SVN side of this that I prefer the same (keeping DB settings out of the repository). Alas.Plus (as I think you're conceding) the problem remains. Substitute "a commented-out call to a long-running function not needed during testing" for "database connection string" as the change I don't want to commit (but don't want to have to constantly reapply).
benizi
A: 

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)

Ben Clifford
This seemed promising, but I don't really see how it's any better than: (1) `git stash` (2) `git svn fetch` (3) `git stash apply`. Still has the same "have to do three things" problem.
benizi
if you're looking to specifically remove having to type in those three commands, a shell-script to do them is a very git-like thing to do. Lots of the higher level stuff in git originated as shell scripts around the lower level stuff (the 'porcelein' that goes around the 'plumbing') to address a specific need...
Ben Clifford
Oops, missed this comment. No, it's not the having-to-type problem that bugs me. Rather the concept that the patch isn't "really" recorded as part of local history. The workaround that I posted avoids it; the local patch is integrated into the git-svn branch, but not checked in to the SVN repo. But it seems hackish.
benizi
If you want it recorded as part of local history, does @akaihola's answer do anything for you?
bstpierre
A: 

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.

akaihola
I do very similar to this, but I just keep a "debug" branch that I rebase onto the master when I need my personalized settings.
Marcus Griep
+1  A: 

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.

iwein