Re: are hashes calculated from data

> On Fri, Apr 2, 2010 at 2:10 AM, Peter Baumann <waste.manager@gmx.de> 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.
> 

> 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.
>