Harness the power of signify(1) to sign arbitrary git objects
update signature format in readme
+8
-7
+8
-7
README.md
+8
-7
README.md
···
64
64
100644 blob aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa algorithm
65
65
100644 blob bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb signature
66
66
100644 blob cccccccccccccccccccccccccccccccccccccccc version
67
+
?????? ???? dddddddddddddddddddddddddddddddddddddddd object
67
68
```
68
69
69
-
Another git object `object` may be present in the tree, if a signature
70
-
over a blob or another tree is being made. This `object` is a pointer
71
-
to the respective git object being signed over. On the other hand,
72
-
`signature` contains the base64 encoded `signify` or `minisign` signature
73
-
over the raw (20 byte) id of `object`. The remaining blobs, `version` and
74
-
`algorithm`, represent the current version of the `git-signify` tree format
75
-
and the algorithm (`minisign` or `signify`) being used, respectively.
70
+
The entry `object` is a pointer to the respective git object being
71
+
signed over, which typically assumes the form of a commit object.
72
+
On the other hand, `signature` contains the base64 encoded `signify` or
73
+
`minisign` signature over the raw (20 byte) id of `object`. The remaining
74
+
blobs, `version` and `algorithm`, represent the current version of the
75
+
`git-signify` tree format and the algorithm (`minisign` or `signify`)
76
+
being used, respectively.
76
77
77
78
The tree is then committed along with a potential parent, which is the commit
78
79
hash being signed over, if any. The resulting commit's hash is returned by