From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-dev+bounces-52102-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1SaPy8-0003yB-KC
for garchives@archives.gentoo.org; Fri, 01 Jun 2012 11:24:36 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 4CA1CE02CB;
Fri, 1 Jun 2012 11:24:17 +0000 (UTC)
Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181])
by pigeon.gentoo.org (Postfix) with ESMTP id 1CB42E055B
for <gentoo-dev@lists.gentoo.org>; Fri, 1 Jun 2012 11:23:34 +0000 (UTC)
Received: by werj55 with SMTP id j55so1464500wer.40
for <gentoo-dev@lists.gentoo.org>; Fri, 01 Jun 2012 04:23:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type:content-transfer-encoding;
bh=4hHMng1oT1ulL9z1DtR0dgMSrv+cBX/t3GFPjno0dEw=;
b=Uc/6YjAlaBztyq3BhZV4eFOVD9/vaA7/8h3BykpL1BD262hwCljIiqxR3Vro06I0nE
CiG3IDldf+mykrXnCaithAPanm33u/Siz2uG0ztH4RWmHISg/aUewrf3WCNmt/k43qkI
gG8cK4Y5YBBBZY2QYCL3HnM3BotdVyH5wHumhI8y0RF7jpKnDGIw3riALas56I3miPIl
xD3el2J/8HhxQLhuLz5j6RR8tYk2K23svhfocO/H3BPEPkM1U+GSEbvEfRmU9O2RYN9w
+kP876u+ttb4V+7HjlGkKLLJnr19jWXv7TN1yU/Kc4D1sagSGBLj0ngzSF29JnFDSv59
W9Dg==
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.216.144.139 with SMTP id n11mr1903571wej.30.1338549814196;
Fri, 01 Jun 2012 04:23:34 -0700 (PDT)
Received: by 10.194.60.167 with HTTP; Fri, 1 Jun 2012 04:23:34 -0700 (PDT)
In-Reply-To: <CAGfcS_k9SHiRbzXee14giw6eF53whPR4K=6KC6roSbs8mDRXMQ@mail.gmail.com>
References: <ddd8ff651a1f5d00ea13fbd9e105ddfa@omrb.pnpi.spb.ru>
<CAGfcS_kOCDZ6Ur37+YYx4DR+1b3c-VWE6eNiefS7HJbqtuKKJA@mail.gmail.com>
<pan.2012.05.30.09.38.51@cox.net>
<CAKmKYaCgdi8uFssF=7rMhAunAs4=qRPgycT0uJYLVGQOhXkuLA@mail.gmail.com>
<CAGfcS_kezhc3ZyfU6Kt1kXCDZqd3VydTjF3BeSt2moEDkbaOSA@mail.gmail.com>
<pan.2012.05.30.13.06.45@cox.net>
<robbat2-20120530T183226-760252197Z@orbis-terrarum.net>
<CAKmKYaBPFXtgPVtY4UQvnD1AjN0oYRz0cDLmZuGzPNNSGnS9YQ@mail.gmail.com>
<robbat2-20120531T163959-415201853Z@orbis-terrarum.net>
<CAGfcS_mSMrS5oYJL3+v2qiCN=efNPestH3je2L7fLvmch2sdVQ@mail.gmail.com>
<20120531191804.GA24784@linux1>
<20120531213303.57529c85@pomiocik.lan>
<79847e2567d341102303362662063b0d@omrb.pnpi.spb.ru>
<CAATnKFDDg-3Kp-z5STFa8QxMPyd9EcQRoXkZMkeF2LkpW0V3Xw@mail.gmail.com>
<CAGfcS_nGgOpA2BdPOA++M3EeG6j34KpAsNexuZ=zN6s-YqqW5Q@mail.gmail.com>
<CAATnKFA814-G3NwaNddmmjnN=5L5tOsk1dw+SHO861STwkfrZQ@mail.gmail.com>
<CAGfcS_k9SHiRbzXee14giw6eF53whPR4K=6KC6roSbs8mDRXMQ@mail.gmail.com>
Date: Fri, 1 Jun 2012 23:23:34 +1200
Message-ID: <CAATnKFA0qe4n55Yv1j2DJZYPwrV8pVaeBi+MRO1r4wLUfJrE_w@mail.gmail.com>
Subject: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
From: Kent Fredric <kentfredric@gmail.com>
To: gentoo-dev@lists.gentoo.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt: 0df72c33-1b43-45b2-acd9-53a70324ac62
X-Archives-Hash: 2e06578d6e5c85c3e9a388c0d9338266
On 1 June 2012 22:54, Rich Freeman <rich0@gentoo.org> wrote:
> On Fri, Jun 1, 2012 at 12:55 AM, Kent Fredric <kentfredric@gmail.com> wro=
te:
>>
>> Hmm, thats annoying. Almost makes me wish it was the trees that were
>> signed, not the commits.
>
> I think it is the tree that is signed, but that changes too.
Nope, at least not as far as I can tell, and I just implemented commit
signature verification >_>
> Rebasing re-applies the same diff to the new head to give you a new
> set of commits. =C2=A0When you apply the same diff to a different parent
> you end up with a different tree, so the tree signature won't be the
> same either.
Not nessecarily. Given that :
a file with a given content has a fixed SHA
A tree is just a list of these SHA's , and that in turn is referenced
by SHA, so if 2 commits have identical file content, their 'tree' sha
will be the same ( in theory ).
So that means, if you perform a rebase, assuming the filesystem looks
the same as it did before the rebase, it will have the same SHA1 for
the tree, regardless of the process of how it got to be that way.
The only SHA that has to change is the 'parent',
( Demonstration here: https://gist.github.com/2851330 , note I have 2
commits with the same tree sha, and the tree sha only really refers to
one file 3 times as all the empty files have same sha )
But unfortunately, with a rebase, even if the trees don't change, if
the history order changes, the commits themselves have to change due
to the "parent" sha needing to change ( yes, I know commits are
immutable in reality, and they don't change, but are duplicated and
the duplicate is given the new sha , but the effect is still the same
, because those unreferenced commits will eventually get reaped )
--=20
Kent
perl -e=C2=A0 "print substr( \"edrgmaM=C2=A0 SPA NOcomil.ic\\@tfrken\", \$_=
* 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"
http://kent-fredric.fox.geek.nz