| 1 |
On Mon, 9 May 2016 05:07:45 +1200 |
| 2 |
Kent Fredric <kentfredric@×××××.com> wrote: |
| 3 |
|
| 4 |
> On 9 May 2016 at 05:03, Alexis Ballier <aballier@g.o> wrote: |
| 5 |
> > I was under the impression that merging is needed in order to |
| 6 |
> > preserve commit signatures when e.g. merging someone else's work. |
| 7 |
> |
| 8 |
> |
| 9 |
> Correct, but if the person applying the commits to tree is in fact |
| 10 |
> reviewing them as they go, then the fact they re-sign it with their |
| 11 |
> own signature |
| 12 |
> ( and changing the commits "Committed by" in the process ) pretty much |
| 13 |
> means the chain of custody is preserved. |
| 14 |
|
| 15 |
|
| 16 |
yeah, i think we have the same chain of custody with ssh push auth + |
| 17 |
safe servers + ssl pull, we don't need signing for this. |
| 18 |
|
| 19 |
> That is, the fact the original signature is lost is immaterial, |
| 20 |
> because we only need it as a signature that /somebody/ actually is |
| 21 |
> responsible for the commit, and the person performing the rebase takes |
| 22 |
> the essential responsibility in the process. |
| 23 |
|
| 24 |
|
| 25 |
well, then I can commit crap with --author mrp@g.o and claim he |
| 26 |
made me rebase it :) |
| 27 |
I understand gpg signing of commits as a way to guarantee author is |
| 28 |
correctly set and claims the commit. |
| 29 |
|
| 30 |
|
| 31 |
Alexis. |
Archives