On 2 June 2012 00:42, Rich Freeman <ri...@gentoo.org> wrote: > On Fri, Jun 1, 2012 at 7:23 AM, Kent Fredric <kentfred...@gmail.com> wrote: >> >> 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. If you have an example of a signed > 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. I want a copy of the > actual file containing the signature. If the signature is embedded in > the commit then I want the file in the objects directory tree that > contains the commit. They'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. If there were 14 > commits B1..14 you'd end up with 14 commits D1.14 that each contain > the line 4a. None 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. 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 == x can be true, as long as z = -y ) > At least, that is my understanding of rebasing. Again, 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. Once you grok > 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 =p -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
