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 ) id 1SaSzj-0000Ek-Kn for garchives@archives.gentoo.org; Fri, 01 Jun 2012 14:38:27 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 33A52E0652; Fri, 1 Jun 2012 14:38:07 +0000 (UTC) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 2CC0CE0128 for ; Fri, 1 Jun 2012 14:37:30 +0000 (UTC) Received: by wgbfm10 with SMTP id fm10so1826745wgb.10 for ; Fri, 01 Jun 2012 07:37:30 -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=+JAtlHoO/31jHjejgEJOyFbULS2rMsx7jis0GmqCLtI=; b=q+2ZPpTApVNYBM+GuWB2jiByfkLUvWD71L9bg8Hu/uOU4QOwPd5c8p+hLHkPL2aCzf ZSt7PUxdayWi7Nw7jlNa/UHeZ9OD15XuJIv/bAEtgxArf2HX7L5EvPNT+idLNmmVxyMO IU8sLqrbmPe3y2bTPZ9F15M8IOqw5e7AgjY67sLuoXuSKxPd3jhc31AjLHbuRo6wMZ3H +ggI575Tnf/sisaBbNbYRTII6oTCOOxouh5OW7FMVb2UFAp8oskQ5VShzZlU5DiFx93s W6VZLEZr14JB80mx/xBF0i3TlHMGvZC24SlXaBHNXU0Y5T4wTXIXsdURixT/40hVW84s nnqw== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.216.210.34 with SMTP id t34mr2311217weo.171.1338561450270; Fri, 01 Jun 2012 07:37:30 -0700 (PDT) Received: by 10.194.60.167 with HTTP; Fri, 1 Jun 2012 07:37:30 -0700 (PDT) In-Reply-To: References: <20120531191804.GA24784@linux1> <20120531213303.57529c85@pomiocik.lan> <79847e2567d341102303362662063b0d@omrb.pnpi.spb.ru> Date: Sat, 2 Jun 2012 02:37:30 +1200 Message-ID: Subject: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver From: Kent Fredric To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: d66b50ae-e3f5-44e0-85fd-1fbb8a2af113 X-Archives-Hash: 9e9e624c5a31e72744a14b0589681451 On 2 June 2012 00:42, Rich Freeman wrote: > On Fri, Jun 1, 2012 at 7:23 AM, Kent Fredric wrot= e: >> >> Nope, at least not as far as I can tell, and I just implemented commit >> signature verification >_> > > I've been trying to find an example of a signed commit, but can't find > one anywhere, so it is hard to tell what it is doing without going > through the git source carefully. =C2=A0If you have an example of a signe= d > commit feel free to send it to me. > > Note that I am NOT interested in the output of any git operation (such > as git log --show-signature, git show, etc) - these are all processed > and do not reveal what is actually going on. =C2=A0I want a copy of the > actual file containing the signature. =C2=A0If the signature is embedded = in > the commit then I want the file in the objects directory tree that > contains the commit. =C2=A0They're just compressed text files (though it = is > a bit of a pain to decompress them). "git cat-file -p $sha" is as close as you can get to commit objects without needing to write your own decompressing wrapper. But it gives the same results. Here is a sample signed git commit ( sans compression ) : https://gist.github.com/2852363 Line 5 to 21 are where the GPG signature is stored. ( Git uses the leading space on all the lines of the GPG sig to indicate that its part of the signature, line 22 does not lead with a space, so that line is after the GPG signature. Line 22 also is empty, which ends the "header" section of the commit, and there starts the "comment" section. If you don't believe me that "git cat-file -p $sha" is reliable, here is a simple script that has no git internals in it , its just Zlib decompression : https://gist.github.com/2852411 perl /tmp/deflate.pl .git/objects/66/50c09ad7b2a62e28476e639654443015ac5945 And that re-emits exactly the same thing : https://gist.github.com/2852363 And if you want to do that yourself, here's that object in compressed form base64 encoded https://gist.github.com/2852436 > The filesystem WON'T look the same after a rebase. > > quick example (operations done in this order): > > file in commit A in master: > 1 > 2 > 3 > 4 > 5 > > file in commit B in a branch off of master: > 1 > 2a > 3 > 4 > 5 > > file in commit C in master: > 1 > 2 > 3 > 4a > 5 > > if you merge master into the branch you'll end up with a new commit D > whose parent is B that looks like: > 1 > 2a > 3 > 4a > 5 > > if instead you rebase master into the branch you'll end up with a new > commit D whose parent is C that looks like: > 1 > 2a > 3 > 4a > 5 > > The history for the branch will no longer contain B. =C2=A0If there were = 14 > commits B1..14 you'd end up with 14 commits D1.14 that each contain > the line 4a. =C2=A0None of them would use the same trees as B1..14, and > they can't use the same signatures as a result, even if only the tree > was signed. =C2=A0 As far as the new history was concerned, line 4a was > there before the branch was started. It all depends really on how you do the rebase, if the changes in the rebase shadow all the competing changes , or the changes are shadowed out before the rebase, the rebase will be the same afterwards, just with a different history. ie: root -> a -> b -> c -> d( backout of c ) If you had started a branch off "b", and then rebased that branch on top of d, the tree would be in the exact same state, but the history would have changed. And likewise, if the change was : root -> a -> b -> c -> d -> e And you started a branch at b, with commits m, n, o, p , changing the same lines c, d and e changed, and when you rebased, you opted to let the changes in m, n, and o replace the changes in c, d and e, ( which has the same effect as if you had deleted c , d and e, except they're still there in the history ), when you move the branch from b to e, the last commit of that branch (p) will still be the same. The rebased commits m, n, and o will be different to what they were when they were on "b", because now they're not only making changes vs "b", but they're also replacing code added in c, d, and e. Sure, this only happens in certain circumstances, and usually when it happens, its because you want it to happen , but it does happen, and its quite useful sometimes. ( essentially, x + y + z =3D=3D x can be true, as long as z =3D -y ) > At least, that is my understanding of rebasing. =C2=A0Again, I'm a bit of= a > git novice, but I never really grokked git until I saw a presentation > that didn't start with commands, but instead started out with just > walking through the actual structure of the repository. =C2=A0Once you gr= ok > the COW model I find it all clicks into place. Yeah, chapter 9 of the Pro Git book is where I recommend everyone with even a sliver of comp-sci knowledge to start. http://www.git-scm.com/book/en/Git-Internals Once you see its basically a bunch of text files, that refer to each other via sha1 , and are stored in files named after their sha1, ( after a bit of compression ), all that graph theory just clicks and you wonder how they managed to make the UI so complicated =3Dp --=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