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