On Sun, Sep 14, 2014 at 08:04:12PM +0200, Andreas K. Huettel wrote: > > > Deciding on a _commit policy_ should be fairly straightforward and we > > already have one point > > * gpg sign every commit (unless it's a merged branch, then we only care > > about the merge commit) > > +1
Merge commits only happen if we allow non-fast-forward merges. I would personally be against allowing merge commits on the master branch. > > > More things to consider for commit policy are: > > * commit message format (line length, maybe prepend category/PN?) > > this could be done in part by repoman... having a meaningful shortlog would > be > nice. I don't see how repoman could do anything about this, but here is a good description of how to write git commit messages [1]. > > * do we expect repoman to run successfully for every commit (I'd say no)? > > commit no, push yes? +1, every time we push that should indicate a successful repoman run. > > * additional information that must be provided I'm not sure what additional information is being referred to. > > * when to force/avoid merge commits I would be against merge commits on the master branch; everything should be a fast-forward merge. > my take- disallow (by policy) nontrivial rebases by third parties, encourage > trivial rebases Rebases involving commits that are already pushed to master probably shouldn't be allowed. However, rebasing changes *on* master, before they are pushed, is a good thing, because that kills non-fast-forward merges. William
signature.asc
Description: Digital signature
