are hashes calculated from data

are hashes calculated from data

[Raymond Auge]

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

Re: are hashes calculated from data

[Avery Pennarun]

On Thu, Apr 1, 2010 at 10:31 PM, Raymond Auge <raymond.auge@liferay.com> wrote:
> 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

Re: are hashes calculated from data

[Miles Bader]

Avery Pennarun <apenwarr@gmail.com> writes:
> 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.

Re: are hashes calculated from data

[Avery Pennarun]

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.

Hope this helps.

Avery

Re: are hashes calculated from data

[Peter Baumann]

On Fri, Apr 02, 2010 at 12:48:44AM -0400, Avery Pennarun wrote:
> 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

Re: are hashes calculated from data

[Avery Pennarun]

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.

Have fun,

Avery

Re: are hashes calculated from data

[Peter Baumann]

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

> 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