On 09/15/14 02:34 AM, hasufell wrote:
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.
Pretty please do NOT allow "merge" commits.. they are the bane of evil
for the long term ability to have any sane work-flow. Trying browsing a
commit history after a big merge commit.. or following the parent..
lastly - the "merge" commit itself could be very confusing to some
people when viewed in github. (At least personally I find them
frequently unreadable)
After 5 years of git where I work - they are now banned (policy) and I
wish github would allow them to be banned (non-fast forward) to avoid
mistakes
There's a big debate between merge vs rebase.. I'm not trying to go down
the benefits of one workflow vs the other.. However, if rebase fails..
you can allow merge commits in the future.. The opposite isn't easily
accomplished without squashing history and losing stuff..
