Mailing-List: contact infrastructure-dev-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: infrastructure-dev@apache.org
Date: Thu, 28 Apr 2011 20:53:46 -0700
From: Brian M Dube <bdube@apache.org>
To: infrastructure-dev@apache.org
Subject: Follow up questions for git-svn users
Message-ID: <20110429035346.GD25047@beaver.dehavilland>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)

I think my setup is standard, from what I gleaned from the GitHub
thread (although github is not part of my workflow). My trunk branch
is remote-tracking, where I use git svn rebase and git svn dcommit.

My first question is about keeping topic branches around and updated
for multiple uses. Perhaps this is a bad idea, but it seems like it
should work. I create my topic branch topic1 with trunk as the
starting point. I do the work, committing along the way, and merge
topic1 into trunk when I'm ready for git svn dcommit. Now I'd like to
continue working from topic1, especially if I squashed the merge to
trunk, so that I have access to the history lost by the squash. But
when I use git svn rebase to update trunk, a merge from trunk back
into topic1 makes my history look wrong in gitk.

What I'm trying to do is get the changes that were not part of my own
commit (anything I pulled down with git svn rebase) back into my topic
branch. It seems like it should be a normal fast-forward, but it's
recursive and the history doesn't look right. I abandon the branch at
this point and start a new one for further work.

The second question, what are you doing about svn properties? If my
commits add any files, I then have to switch to my pure svn checkout
and set svn:eol-style and commit from svn.

-Brian