| 1 |
On Sun, Sep 14, 2014 at 3:55 PM, hasufell <hasufell@g.o> wrote: |
| 2 |
> Davide Pesavento: |
| 3 |
>>> In any case, we would likely strip the history anyway to get a small |
| 4 |
>>> repo to work with. |
| 5 |
>>> |
| 6 |
>>> I have prepared a basic git update hook that keeps master clean |
| 7 |
>>> and attached it to the bug [1]. It enforces basic policies, prevents |
| 8 |
>>> forced updates and checks GPG signatures on left-most history line. It |
| 9 |
>>> can also be extended to do more extensive tree checks. |
| 10 |
>> |
| 11 |
>> Are we going to disallow merge commits and ask devs to rebase local |
| 12 |
>> changes in order to keep the history "clean"? |
| 13 |
>> |
| 14 |
> |
| 15 |
> I'd say it doesn't make sense to create merge commits for conflicts that |
| 16 |
> arise by someone having pushed earlier than you. |
| 17 |
> |
| 18 |
> Merge commits should only be there if they give useful information. |
| 19 |
> |
| 20 |
|
| 21 |
I totally agree. But is there a way to automatically enforce this? |
| 22 |
|
| 23 |
> Also... if you merge from a _user_ who is untrusted and allow a |
| 24 |
> fast-forward merge, then the signature verification fails. That means |
| 25 |
> for such pull requests you either have to use "git am" or "git merge |
| 26 |
> --no-ff". |
| 27 |
> |
| 28 |
|
| 29 |
Right. In that case you can either sign the merge commit or amend the |
| 30 |
user's commit and sign it yourself (re-signing could be needed anyway |
| 31 |
if you have to rebase). |
| 32 |
|
| 33 |
Thanks, |
| 34 |
Davide |
Archives