| 1 |
On Sun, Sep 14, 2014 at 08:04:12PM +0200, Andreas K. Huettel wrote: |
| 2 |
> |
| 3 |
> > Deciding on a _commit policy_ should be fairly straightforward and we |
| 4 |
> > already have one point |
| 5 |
> > * gpg sign every commit (unless it's a merged branch, then we only care |
| 6 |
> > about the merge commit) |
| 7 |
> |
| 8 |
> +1 |
| 9 |
|
| 10 |
Merge commits only happen if we allow non-fast-forward merges. I would |
| 11 |
personally be against allowing merge commits on the master branch. |
| 12 |
|
| 13 |
> |
| 14 |
> > More things to consider for commit policy are: |
| 15 |
> > * commit message format (line length, maybe prepend category/PN?) |
| 16 |
> |
| 17 |
> this could be done in part by repoman... having a meaningful shortlog would be |
| 18 |
> nice. |
| 19 |
|
| 20 |
I don't see how repoman could do anything about this, but here is a |
| 21 |
good description of how to write git commit messages [1]. |
| 22 |
|
| 23 |
> > * do we expect repoman to run successfully for every commit (I'd say no)? |
| 24 |
> |
| 25 |
> commit no, push yes? |
| 26 |
|
| 27 |
+1, every time we push that should indicate a successful repoman run. |
| 28 |
|
| 29 |
> > * additional information that must be provided |
| 30 |
|
| 31 |
I'm not sure what additional information is being referred to. |
| 32 |
|
| 33 |
> > * when to force/avoid merge commits |
| 34 |
|
| 35 |
I would be against merge commits on the master branch; everything |
| 36 |
should be a fast-forward merge. |
| 37 |
|
| 38 |
> my take- disallow (by policy) nontrivial rebases by third parties, encourage |
| 39 |
> trivial rebases |
| 40 |
|
| 41 |
Rebases involving commits that are already pushed to master probably |
| 42 |
shouldn't be allowed. |
| 43 |
|
| 44 |
However, rebasing changes *on* master, before they are pushed, is a good |
| 45 |
thing, because that kills non-fast-forward merges. |
| 46 |
|
| 47 |
William |
Archives