[clug] Git help please - I might be breaking branches

[Daniel Pittman]

Alex Satrapa <grail at goldweb.com.au> writes:
> On 23/03/2009, at 15:20 , Daniel Pittman wrote:
>
>> Ah.  I stand corrected: you are not doing this the way that the upstream
>> git-svn developer recommends, but rather with local branches and merges.
>> Oh, well.
>
> Searching Google for assistance in git/svn workflows or best practices pulls
> up more documents like this, and nothing like the scheme hinted  at in the
> manual page:

[...]

> When I started using git-svn I had no idea what that sentence was
> supposed to mean, so I went looking for examples of how people
> actually use it. These suggestions all work nicely, except for the way
> merge commits get transmogrified into patch commits.

*nod*  Yeah, git generally sucks for end user friendly documentation.
It was bad enough that it still takes me some time to work out quite how
bits of it are intended to be used, and I have been dealing with VCS
tools for literally fifteen years now, professionally.

> Working with Subversion the way that's suggested in the manual
> requires continuous access to the Subversion repository, and every
> change you make has to go through Subversion first.

Not quite: I routinely do significant work offline, and my work use a
SVN repository as their central store.

> This doesn't work well for situations where I write tests, then write
> the code to pass the test (I'll end up with lots of commits that break
> the continual integration server).

This is the model I, also, use, along with significant rebasing to
refactor commits in my private repository from "a million trivial
changes" to "some sensible changes".

That doesn't break our CI server, either, since I can make sure it
builds at each stage — or just commit the dozen changes at once, in
which case there the CI server just builds the end result.[1]


> This is antithetical to the attraction of git as a disconnected,
> distributed version control system with cheap branching & merging.

This is where my comments on the mismatch between the git, git-svn and
svn branch models came from: git thinks about history in one way,
git-svn in another, and svn in a third, and even if you don't *use* svn
branches their design still flows into this integration path.

Well, you can keep doing that, so long as you are aware that this will
discard the individual change history of your development branches,
smushing them into one big "merge" commit when they hit SVN.

Using SVN as the integration point preserves those individual steps,
which you may or may not care so much about.


You can also use git cherrypick to pull an individual patch, like a bug
fix, into your current branch, but you shouldn't try to commit it twice
with 'git svn dcommit'.


So, the place that the SVN integration really hurts is when you want to
integrate branches and the SVN repository isn't available.

To address that I just use throw-away integration branches; given:

    git-svn  => svn trunk
    bug123   => local branch from git-svn
    bug124   => ditto

I would do this:

  git checkout git-svn
  git checkout -b integration
  git merge bug123 bug124
  make test   # or whatever
  git branch -D integration

That lets me test those changes appropriately, together, while
preserving the branch development to send up to the SVN repository
nicely.

> What other hazards are awaiting the lazy patchers like myself?

Hard to say.  Nothing obvious springs to mind. :)

Regards,
        Daniel

Footnotes: 
[1]  Technically, I am racing the CI server since it /could/ pick up
     a tree half way through my change series, break, then fix itself
     when it built to the end, but that is rare enough that I just don't
     care.