| 1 |
William Hubbs: |
| 2 |
> On Sun, Sep 14, 2014 at 08:04:12PM +0200, Andreas K. Huettel wrote: |
| 3 |
>> |
| 4 |
>>> Deciding on a _commit policy_ should be fairly straightforward and we |
| 5 |
>>> already have one point |
| 6 |
>>> * gpg sign every commit (unless it's a merged branch, then we only care |
| 7 |
>>> about the merge commit) |
| 8 |
>> |
| 9 |
>> +1 |
| 10 |
> |
| 11 |
> Merge commits only happen if we allow non-fast-forward merges. I would |
| 12 |
> personally be against allowing merge commits on the master branch. |
| 13 |
> |
| 14 |
|
| 15 |
Allowing fast-forward merges will break signature verification if you |
| 16 |
fetched from a user repo. |
| 17 |
If we don't allow merge commits, then _every_ commit hast to be signed |
| 18 |
by a gentoo dev (e.g. by using git-am). I don't see much sense in this. |
| 19 |
It will rather complicate workflow. |
| 20 |
|
| 21 |
The currently proposed verification script skips branch 'B', so what |
| 22 |
matters is the signature of the merge commit which say "yes, I have |
| 23 |
reviewed the users branch(es) and it's fine". |
| 24 |
|
| 25 |
Merging from branches holds useful information. A linear history isn't |
| 26 |
necessarily easier to understand, so from me linear history gets a |
| 27 |
|
| 28 |
-1 |
| 29 |
|
| 30 |
It just isn't really "git" to me. But it also requires people to know |
| 31 |
when to avoid merge commits. |
| 32 |
|
| 33 |
> |
| 34 |
> Rebases involving commits that are already pushed to master probably |
| 35 |
> shouldn't be allowed. |
| 36 |
> |
| 37 |
|
| 38 |
Of course, yes. That has to be documented in a gentoo developer git guide. |
Archives