| 1 |
On Mon, May 9, 2016 at 7:27 AM, Kristian Fiskerstrand <k_f@g.o> wrote: |
| 2 |
> On 05/08/2016 07:07 PM, Kent Fredric wrote: |
| 3 |
>> On 9 May 2016 at 05:03, Alexis Ballier <aballier@g.o> wrote: |
| 4 |
>>> I was under the impression that merging is needed in order to preserve |
| 5 |
>>> commit signatures when e.g. merging someone else's work. |
| 6 |
>> |
| 7 |
>> |
| 8 |
>> Correct, but if the person applying the commits to tree is in fact |
| 9 |
>> reviewing them as they go, then the fact they re-sign it with their |
| 10 |
>> own signature |
| 11 |
>> ( and changing the commits "Committed by" in the process ) pretty much |
| 12 |
>> means the chain of custody is preserved. |
| 13 |
> |
| 14 |
> And it is a requirement in particular in the case where the author is |
| 15 |
> not a gentoo dev as the certificate used for the signature otherwise |
| 16 |
> isn't recognized. The committing developer will need to have a local |
| 17 |
> framework in place for certificate validation to ensure that the author |
| 18 |
> is authentic, after that the committing author is responsible for all |
| 19 |
> behavior of the commit. |
| 20 |
> |
| 21 |
|
| 22 |
Keep in mind that you can have both. You can both preserve the |
| 23 |
original commit with its signature, and introduce it as a merge commit |
| 24 |
with a Gentoo signature. |
| 25 |
|
| 26 |
I'm not saying we necessarily should do this, but certainly git makes |
| 27 |
this possible, and it is a potential benefit of merge commits. |
| 28 |
|
| 29 |
However, in this case it would not be possible to rebase the original |
| 30 |
commit, which introduces some of the uncleanliness of non-rebased |
| 31 |
merge commits. In general I'm a fan of rebasing merge commits. |
| 32 |
|
| 33 |
-- |
| 34 |
Rich |
Archives