[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.
*nod*
>> 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.
Regards,
Daniel
More information about the linux
mailing list