threads / discuss / 23296

are hashes calculated from data

Subject: are hashes calculated from data

## tl;dr

7 messages between Apr 2, 2010 and Apr 2, 2010.

replies: 6people: 4as markdown or json

Raymond Auge· Apr 2, 2010, 02:31 UTC · lore
Hello All,

I was wondering if the hashes are calculated solely from the data or if there is a seed taken from outside.

I ask because I'm wondering the following.

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.

~ Ray
Avery Pennarun· Apr 2, 2010, 02:50 UTC · re: Raymond Auge · lore

Re: are hashes calculated from data

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
Miles Bader· Apr 2, 2010, 04:22 UTC · re: Avery Pennarun · lore

Re: are hashes calculated from data

Avery Pennarun <apenwarr@gmail.com> writes:
Show 17 quoted lines
> 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.
Do you happen to have the cron script available for perusal anywhere?

I imagine many of the details would need to be changed for other installations, but just looking at a working concrete example could be very helpful...

Thanks,
-Miles
-- 
=====
(^o^;
(()))
*This is the cute octopus virus, please copy it into your sig so it can spread.
Avery Pennarun· Apr 2, 2010, 04:48 UTC · re: Miles Bader · lore

Re: are hashes calculated from data

On Fri, Apr 2, 2010 at 12:22 AM, Miles Bader <miles@gnu.org> wrote:
Show 11 quoted lines
> Avery Pennarun <apenwarr@gmail.com> writes:
>> 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.
>
> Do you happen to have the cron script available for perusal anywhere?
>
> I imagine many of the details would need to be changed for other
> installations, but just looking at a working concrete example could be
> very helpful...

Unfortunately the particular script we're using is about 99% local stuff and 1% useful stuff, so posting it won't really help. The pseudocode is something like this:

       # 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/*

And then people who want to push into svn can push into the 'origin' repository, wherever that may be. With some tweaking, you could make the git-svn repo and the origin repo the same. It's a little annoying because git-svn absolutely insists on its branches being in refs/remotes/ somewhere, which means they don't normally get fetched when other people grab from your repo.

Also consider setting [merge]summary=true in your .gitconfig, so that the svn commit will have *some* useful information about what got committed.

Hope this helps.
Avery
Peter Baumann· Apr 2, 2010, 06:10 UTC · re: Avery Pennarun · lore

Re: are hashes calculated from data

On Fri, Apr 02, 2010 at 12:48:44AM -0400, Avery Pennarun wrote:
Show 40 quoted lines
> On Fri, Apr 2, 2010 at 12:22 AM, Miles Bader <miles@gnu.org> wrote:
> > Avery Pennarun <apenwarr@gmail.com> writes:
> >> 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.
> >
> > Do you happen to have the cron script available for perusal anywhere?
> >
> > I imagine many of the details would need to be changed for other
> > installations, but just looking at a working concrete example could be
> > very helpful...
> 
> Unfortunately the particular script we're using is about 99% local
> stuff and 1% useful stuff, so posting it won't really help.  The
> pseudocode is something like this:
> 
>        # 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/*
> 
> And then people who want to push into svn can push into the 'origin'
> repository, wherever that may be.  With some tweaking, you could make
> the git-svn repo and the origin repo the same.  It's a little annoying
> because git-svn absolutely insists on its branches being in
> refs/remotes/ somewhere, which means they don't normally get fetched
> when other people grab from your repo.
> 
> Also consider setting [merge]summary=true in your .gitconfig, so that
> the svn commit will have *some* useful information about what got
> committed.
>

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.
Peter
Avery Pennarun· Apr 2, 2010, 06:49 UTC · re: Peter Baumann · lore

Re: are hashes calculated from data

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
Peter Baumann· Apr 2, 2010, 07:08 UTC · re: Avery Pennarun · lore

Re: are hashes calculated from data

On Fri, Apr 02, 2010 at 02:49:25AM -0400, Avery Pennarun wrote:
Show 35 quoted lines
> 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.
>

Ah. Ok. So I actually was true, meaning "from a SVN standpoint", I just expressed myself not clearly.

Show 11 quoted lines
> 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

← back to recent threads