From: Peter Baumann Date: Fri, 02 Apr 2010 07:08:59 GMT Subject: Re: are hashes calculated from data Message-ID: <20100402070859.GD14999@m62s10.vlinux.de> In-Reply-To: On Fri, Apr 02, 2010 at 02:49:25AM -0400, Avery Pennarun wrote: > On Fri, Apr 2, 2010 at 2:10 AM, Peter Baumann wrote: > > On Fri, Apr 02, 2010 at 12:48:44AM -0400, Avery Pennarun wrote: > >>        # configure your git-svn so that all its branches are under remotes/svn/* > >>        git fetch origin > >>        git svn fetch --fetch-all > >>        for each branch in remotes/svn/* > >>            git checkout remotes/svn/$branch   # detaches HEAD > >>            git merge --no-ff origin/$branch > >>            git svn dcommit   # replaces merge commit > >>            git checkout origin/$branch > >>            git merge remotes/svn/$branch > >>            git push origin HEAD:$branch > >>        git push origin refs/remotes/svn/*:refs/heads/svn/* > > > > If I understand you correctly, this will commit only the the merge to svn > > and won't show all the commits the developer made (because of the --no-ff). > > From a SVN standpoint isn't it the same as doing the following? > > > >        git checkout remotes/svn/$branch        # to deatch the HEAD > >        git merge --squash  origin/$branch > >        git svn dcommit > > > > I asked because in my workflow I can't to afford lossing the single commits. > > No, not quite the same. > > When git-svn replaces your merge commit with a new commit (as part of > the 'git svn dcommit' step) the new commit *stays* a merge commit in > git. That means it has two parents: the svn parent commit, and the > commit that you merged from in the first place. > > So what happens is that svn will see only a single commit, but your > git history remains intact and git push/pulling will continue working > as you expect. > Ah. Ok. So I actually was true, meaning "from a SVN standpoint", I just expressed myself not clearly. > If you really need svn to see every individual commit, then you're out > of luck. The only way to do it is to rebase every time you want to > commit to svn. git-svn then replaces every single one of your commits > (essentially another rebase, so it can add the git-svn: tags to the > commit message) which makes push/pulling between git repos impossible. > > So those are your two choices. Personally, I like my way as a > transition plan, because the git repo keeps the precise history > (including forks and merges), while the svn keeps *working* for the > stragglers who want to keep using it. > Thx for your explanation, Peter