| 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 |
Archives