Re: are hashes calculated from data

From: Avery Pennarun <apenwarr@gmail.com>
Date: Apr 2, 2010, 02:50 UTC
Message-ID: <o2q32541b131004011950u6023ef29ocac1d80f2847ef6f@mail.gmail.com>
In-Reply-To: <g2veaacf13c1004011931w70695d1emdceeb977397aee0d@mail.gmail.com>

On Thu, Apr 1, 2010 at 10:31 PM, Raymond Auge <raymond.auge@liferay.com> wrote:

Show 9 quoted lines

> Given two separate git repositories initialized from the same
> subversion repository, if the hashes are calculated from the data
> alone, then those two repositories could theoretically pull/push
> branches from each other while retaining  the ability to commit back
> to the "origin" subversion repository.
>
> If this is in fact the case, it would make it quite simple for me to
> convince the more ambitious developers on our team to use git locally,
> and grow team usage in a passive, viral way.

This *almost* works. The problem is 'git svn dcommit'. It eats your git-created commits, and generates *new* ones by committing back to svn and then retrieving the newly-created commits. It's essentially the same as rebasing, which makes future git merges not really work.

You can minimize the impact of this problem, however.  The easiest way is:

- have only a single person use git-svn

- when committing stuff to git-svn, first checkout the *existing*
git-svn branch, then use "git merge --no-ff mybranch", then "git svn
dcommit".  The --no-ff is very important; this makes sure that a *new*
commit is created (a merge commit) for the svn dcommit.  svn dcommit
then creates only a single svn commit that includes all the patches
from the whole branch.

- then do 'git checkout mybranch; git merge git-svn' to get the svn commit back.

At work, we have a cronjob that basically does most of these steps for us. Then there's a central git repo that corresponds to the svn repo; people who want to use git can use that repo and not worry about git-svn.

Hope this helps.

Have fun,

Avery