1 |
On 2 June 2012 00:42, Rich Freeman <rich0@g.o> wrote: |
2 |
> On Fri, Jun 1, 2012 at 7:23 AM, Kent Fredric <kentfredric@×××××.com> wrote: |
3 |
>> |
4 |
>> Nope, at least not as far as I can tell, and I just implemented commit |
5 |
>> signature verification >_> |
6 |
> |
7 |
> I've been trying to find an example of a signed commit, but can't find |
8 |
> one anywhere, so it is hard to tell what it is doing without going |
9 |
> through the git source carefully. If you have an example of a signed |
10 |
> commit feel free to send it to me. |
11 |
> |
12 |
> Note that I am NOT interested in the output of any git operation (such |
13 |
> as git log --show-signature, git show, etc) - these are all processed |
14 |
> and do not reveal what is actually going on. I want a copy of the |
15 |
> actual file containing the signature. If the signature is embedded in |
16 |
> the commit then I want the file in the objects directory tree that |
17 |
> contains the commit. They're just compressed text files (though it is |
18 |
> a bit of a pain to decompress them). |
19 |
|
20 |
"git cat-file -p $sha" is as close as you can get to commit objects |
21 |
without needing to write your own decompressing wrapper. But it gives |
22 |
the same results. |
23 |
|
24 |
Here is a sample signed git commit ( sans compression ) : |
25 |
|
26 |
https://gist.github.com/2852363 |
27 |
|
28 |
Line 5 to 21 are where the GPG signature is stored. ( Git uses the |
29 |
leading space on all the lines of the GPG sig to indicate that its |
30 |
part of the signature, line 22 does not lead with a space, so that |
31 |
line is after the GPG signature. Line 22 also is empty, which ends |
32 |
the "header" section of the commit, and there starts the "comment" |
33 |
section. |
34 |
|
35 |
If you don't believe me that "git cat-file -p $sha" is reliable, here |
36 |
is a simple script that has no git internals in it , its just Zlib |
37 |
decompression : https://gist.github.com/2852411 |
38 |
|
39 |
perl /tmp/deflate.pl .git/objects/66/50c09ad7b2a62e28476e639654443015ac5945 |
40 |
|
41 |
And that re-emits exactly the same thing : https://gist.github.com/2852363 |
42 |
|
43 |
And if you want to do that yourself, here's that object in compressed |
44 |
form base64 encoded https://gist.github.com/2852436 |
45 |
|
46 |
|
47 |
> The filesystem WON'T look the same after a rebase. |
48 |
> |
49 |
> quick example (operations done in this order): |
50 |
> |
51 |
> file in commit A in master: |
52 |
> 1 |
53 |
> 2 |
54 |
> 3 |
55 |
> 4 |
56 |
> 5 |
57 |
> |
58 |
> file in commit B in a branch off of master: |
59 |
> 1 |
60 |
> 2a |
61 |
> 3 |
62 |
> 4 |
63 |
> 5 |
64 |
> |
65 |
> file in commit C in master: |
66 |
> 1 |
67 |
> 2 |
68 |
> 3 |
69 |
> 4a |
70 |
> 5 |
71 |
> |
72 |
> if you merge master into the branch you'll end up with a new commit D |
73 |
> whose parent is B that looks like: |
74 |
> 1 |
75 |
> 2a |
76 |
> 3 |
77 |
> 4a |
78 |
> 5 |
79 |
> |
80 |
> if instead you rebase master into the branch you'll end up with a new |
81 |
> commit D whose parent is C that looks like: |
82 |
> 1 |
83 |
> 2a |
84 |
> 3 |
85 |
> 4a |
86 |
> 5 |
87 |
> |
88 |
> The history for the branch will no longer contain B. If there were 14 |
89 |
> commits B1..14 you'd end up with 14 commits D1.14 that each contain |
90 |
> the line 4a. None of them would use the same trees as B1..14, and |
91 |
> they can't use the same signatures as a result, even if only the tree |
92 |
> was signed. As far as the new history was concerned, line 4a was |
93 |
> there before the branch was started. |
94 |
|
95 |
It all depends really on how you do the rebase, if the changes in the |
96 |
rebase shadow all the competing changes , or the changes are shadowed |
97 |
out before the rebase, the rebase will be the same afterwards, just |
98 |
with a different history. |
99 |
|
100 |
ie: |
101 |
|
102 |
root -> a -> b -> c -> d( backout of c ) |
103 |
|
104 |
If you had started a branch off "b", and then rebased that branch on |
105 |
top of d, the tree would be in the exact same state, but the history |
106 |
would have changed. |
107 |
|
108 |
And likewise, if the change was : |
109 |
|
110 |
root -> a -> b -> c -> d -> e |
111 |
|
112 |
And you started a branch at b, with commits m, n, o, p , changing the |
113 |
same lines c, d and e changed, |
114 |
and when you rebased, you opted to let the changes in m, n, and o |
115 |
replace the changes in c, d and e, |
116 |
( which has the same effect as if you had deleted c , d and e, except |
117 |
they're still there in the history ), when you move the branch from b |
118 |
to e, the last commit of that branch (p) will still be the same. |
119 |
|
120 |
The rebased commits m, n, and o will be different to what they were |
121 |
when they were on "b", because now they're not only making changes vs |
122 |
"b", but they're also replacing code added in c, d, and e. |
123 |
|
124 |
Sure, this only happens in certain circumstances, and usually when it |
125 |
happens, its because you want it to happen , but it does happen, and |
126 |
its quite useful sometimes. |
127 |
|
128 |
( essentially, x + y + z == x can be true, as long as z = -y ) |
129 |
|
130 |
|
131 |
> At least, that is my understanding of rebasing. Again, I'm a bit of a |
132 |
> git novice, but I never really grokked git until I saw a presentation |
133 |
> that didn't start with commands, but instead started out with just |
134 |
> walking through the actual structure of the repository. Once you grok |
135 |
> the COW model I find it all clicks into place. |
136 |
|
137 |
Yeah, chapter 9 of the Pro Git book is where I recommend everyone with |
138 |
even a sliver of comp-sci knowledge to start. |
139 |
http://www.git-scm.com/book/en/Git-Internals |
140 |
|
141 |
Once you see its basically a bunch of text files, that refer to each |
142 |
other via sha1 , and are stored in files named after their sha1, ( |
143 |
after a bit of compression ), all that graph theory just clicks and |
144 |
you wonder how they managed to make the UI so complicated =p |
145 |
|
146 |
|
147 |
|
148 |
|
149 |
-- |
150 |
Kent |
151 |
|
152 |
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, |
153 |
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" |
154 |
|
155 |
http://kent-fredric.fox.geek.nz |