Gentoo Archives: gentoo-dev

From: Alexey Shvetsov <alexxy@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
Date: Fri, 01 Jun 2012 12:49:49
Message-Id: b6d08157fa5ce9a253b8e7af02787e49@omrb.pnpi.spb.ru
In Reply to: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver by Rich Freeman
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