1 |
Hi! |
2 |
|
3 |
Check kde overlay ;) we used signed commits here |
4 |
|
5 |
Rich Freeman писал 2012-06-01 16:42: |
6 |
> On Fri, Jun 1, 2012 at 7:23 AM, Kent Fredric <kentfredric@×××××.com> |
7 |
> wrote: |
8 |
>> |
9 |
>> Nope, at least not as far as I can tell, and I just implemented |
10 |
>> commit |
11 |
>> signature verification >_> |
12 |
> |
13 |
> I've been trying to find an example of a signed commit, but can't |
14 |
> find |
15 |
> one anywhere, so it is hard to tell what it is doing without going |
16 |
> through the git source carefully. If you have an example of a signed |
17 |
> commit feel free to send it to me. |
18 |
> |
19 |
> Note that I am NOT interested in the output of any git operation |
20 |
> (such |
21 |
> as git log --show-signature, git show, etc) - these are all processed |
22 |
> and do not reveal what is actually going on. I want a copy of the |
23 |
> actual file containing the signature. If the signature is embedded |
24 |
> in |
25 |
> the commit then I want the file in the objects directory tree that |
26 |
> contains the commit. They're just compressed text files (though it |
27 |
> is |
28 |
> a bit of a pain to decompress them). |
29 |
> |
30 |
>> Not nessecarily. Given that : |
31 |
>> |
32 |
>> a file with a given content has a fixed SHA |
33 |
>> A tree is just a list of these SHA's , and that in turn is |
34 |
>> referenced |
35 |
>> by SHA, so if 2 commits have identical file content, their 'tree' |
36 |
>> sha |
37 |
>> will be the same ( in theory ). |
38 |
>> |
39 |
>> So that means, if you perform a rebase, assuming the filesystem |
40 |
>> looks |
41 |
>> the same as it did before the rebase, it will have the same SHA1 for |
42 |
>> the tree, regardless of the process of how it got to be that way. |
43 |
> |
44 |
> The filesystem WON'T look the same after a rebase. |
45 |
> |
46 |
> quick example (operations done in this order): |
47 |
> |
48 |
> file in commit A in master: |
49 |
> 1 |
50 |
> 2 |
51 |
> 3 |
52 |
> 4 |
53 |
> 5 |
54 |
> |
55 |
> file in commit B in a branch off of master: |
56 |
> 1 |
57 |
> 2a |
58 |
> 3 |
59 |
> 4 |
60 |
> 5 |
61 |
> |
62 |
> file in commit C in master: |
63 |
> 1 |
64 |
> 2 |
65 |
> 3 |
66 |
> 4a |
67 |
> 5 |
68 |
> |
69 |
> if you merge master into the branch you'll end up with a new commit D |
70 |
> whose parent is B that looks like: |
71 |
> 1 |
72 |
> 2a |
73 |
> 3 |
74 |
> 4a |
75 |
> 5 |
76 |
> |
77 |
> if instead you rebase master into the branch you'll end up with a new |
78 |
> commit D whose parent is C that looks like: |
79 |
> 1 |
80 |
> 2a |
81 |
> 3 |
82 |
> 4a |
83 |
> 5 |
84 |
> |
85 |
> The history for the branch will no longer contain B. If there were |
86 |
> 14 |
87 |
> commits B1..14 you'd end up with 14 commits D1.14 that each contain |
88 |
> the line 4a. None of them would use the same trees as B1..14, and |
89 |
> they can't use the same signatures as a result, even if only the tree |
90 |
> was signed. As far as the new history was concerned, line 4a was |
91 |
> there before the branch was started. |
92 |
> |
93 |
> At least, that is my understanding of rebasing. Again, I'm a bit of |
94 |
> a |
95 |
> git novice, but I never really grokked git until I saw a presentation |
96 |
> that didn't start with commands, but instead started out with just |
97 |
> walking through the actual structure of the repository. Once you |
98 |
> grok |
99 |
> the COW model I find it all clicks into place. |
100 |
> |
101 |
> Rich |
102 |
|
103 |
-- |
104 |
Best Regards, |
105 |
Alexey 'Alexxy' Shvetsov |
106 |
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, |
107 |
Gatchina, Russia |
108 |
Department of Molecular and Radiation Biophysics |
109 |
Gentoo Team Ru |
110 |
Gentoo Linux Dev |
111 |
mailto:alexxyum@×××××.com |
112 |
mailto:alexxy@g.o |
113 |
mailto:alexxy@×××××××××××××.ru |