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

Daniel Pittman daniel at rimspace.net
Mon Mar 23 04:20:58 GMT 2009

Alex Satrapa <grail at goldweb.com.au> writes:
> On 23/03/2009, at 13:49 , Daniel Pittman wrote:

[... git svn rebase ...]

>> That will fetch changes automatically, but only for the current
>> branch parent in SVN,
> That's all I want to achieve - svn-trunk in my git repository is the
> branch that I'm keeping in sync with the Subversion repository.


>> Yes, it is both safe and the recommend 'git svn' practice to work in
>> this way: the upstream author recommends using dcommit and rebase to
>> merge upstream changes rather than git merge.
> I get stuff from Subversion to svn-trunk, then locally branch to
> "ticket-123", work locally to resolve the ticket, then locally merge
> back to the git branch named "svn-trunk". These are not upstream
> changes, these are changes i end up pushing back to the upstream using
> dcommit. Any changes that happen upstream are taken into account
> during my subversion dance steps of fetch/rebase.

Ah.  I stand corrected: you are not doing this the way that the upstream
git-svn developer recommends, but rather with local branches.  Oh, well.

>> This is the logical fallout from that, where there is a slight mismatch
>> between the git branch model, the svn branch model and the git svn
>> branch model.
> There are no Subversion branches other than Trunk involved in these
> operations.

*nod*  There is still a mismatch between what Subversion thinks of as a
branch and what git thinks of one as, which is the root cause of this
complaint from git.

> Thus the "git checkout -b ticket-123" which has absolutely no effect
> on Subversion. Don't let the name "svn-trunk" fool you - all this work
> is happening locally in my git-controlled environment.

I am aware of that, even if I misunderstood your description of quite
how you interact with the Subversion repository.


More information about the linux mailing list