Question

I’m working on a project that is using code from an OpenSource project. One of the requirements is to push as much code back to upstream as possible.

The remote project is using Subversion (not very well).

My current setup looks like this:

[Remote SVN] (git svn fetch)-> [My public Git] <-(push/pull)-> [My dev. Git]
                                    VV
                                  (pull)
                                    VV
                               [Testing grid]

EDIT 11.7. – reformulated the question

My issue is the coexistence of my local public repo and the svn upstream.

I have to provide 3 public branches:

• conservative stable
• experimental stable
• development

These branches are now linear (development becomes experimental stable and experimental becomes conservative), but the target is a standard 3 headed approach with merging. Due to their public nature I can’t rebase these branches.

Now completely orthogonal to this I’m trying to somehow make sending patches to upstream easier. Digging them out from my branches is slow and prone to errors.

My typical current workflow is:

• implement some feature on top development branch
• test & fix feature
• test & fix other features broken by this new feature (actually happens a lot)
• determine if this is something that could be accepted in upstream or not (30:60 yes:no)
• do something about it (I usually just write a new TODO)

Another problem with the upstream is that they accept patches into different branches (my public branches are based on their stable branch). Once the patches reach stable branch I can simply forget that they exist, but until that happens I need to still keep them locally.

Answer 1

The git svn documentation recommends the following workflow when dealing with Subversion branches:

# Clone a repo (like git clone):
git svn clone http://svn.example.com/project -T trunk -b branches -t tags

# Append svn:ignore settings to the default git exclude file:
git svn show-ignore >> .git/info/exclude

# View all branches and tags you have cloned:
git branch -r

# Create a new branch in SVN
git svn branch waldo

# Reset your master to waldo:
git reset --hard remotes/waldo

# local changes
git add ...
git commit ...

# pull changes on current branch
git svn rebase

# send changes to Subversion
git svn dcommit

# check for new branches
git svn fetch

The workflow above is for an uninterrupted change on a single Subversion branch to which you have the luxury of a commit bit, but juggling multiple active Subversion and git branches is a little tricky.

To track the Subversion repository’s waldo branch, start off with

git checkout -b waldo-svn remotes/waldo

The -svn suffix is to avoid warnings of the form

warning: refname 'waldo' is ambiguous.

and also to remind you that this git branch is for tracking the Subversion branch. Always keep changes to these branches linear!

To update waldo-svn, run

git svn rebase

This will fetch the changes from Subversion and rebase any local changes on top of those. It’s also smart enough to recognize when one of your local changes has been accepted verbatim upstream: it will be replaced by the Subversion commit and have a line beginning with git-svn-id: ... in its commit message.

When the upstream maintainers alter the contents and structure of your patches (e.g., modifying the code, splitting a patch into multiple Subversion commits, or combining multiple patches into a single commit) is when life gets fun resolving conflicts and trying to untangle the mess.

For full generality, keep your -svn branches in git clean (no changes) and create issue branches off the -svn branches. To send a patch, use

git diff waldo-svn waldo-fix-frobnicator

Then when you git svn rebase to catch up with the Subversion repo, you’ll need to review the log and decide on the respective dispositions of your issue branches, sort of a GTD for git.