Re: are hashes calculated from data

From: Avery Pennarun <apenwarr@gmail.com>
Date: Apr 2, 2010, 06:49 UTC
Message-ID: <z2i32541b131004012349na7af3571j67c3a33e3e3ba78@mail.gmail.com>
In-Reply-To: <20100402061015.GC14999@m62s10.vlinux.de>

On Fri, Apr 2, 2010 at 2:10 AM, Peter Baumann <waste.manager@gmx.de> wrote:

Show 22 quoted lines

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

Have fun,

Avery