William Hubbs: > 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. >
Allowing fast-forward merges will break signature verification if you fetched from a user repo. If we don't allow merge commits, then _every_ commit hast to be signed by a gentoo dev (e.g. by using git-am). I don't see much sense in this. It will rather complicate workflow. The currently proposed verification script skips branch 'B', so what matters is the signature of the merge commit which say "yes, I have reviewed the users branch(es) and it's fine". Merging from branches holds useful information. A linear history isn't necessarily easier to understand, so from me linear history gets a -1 It just isn't really "git" to me. But it also requires people to know when to avoid merge commits. > > Rebases involving commits that are already pushed to master probably > shouldn't be allowed. > Of course, yes. That has to be documented in a gentoo developer git guide.
