| 1 |
On 09/15/14 02:34 AM, hasufell wrote: |
| 2 |
> William Hubbs: |
| 3 |
>> On Sun, Sep 14, 2014 at 08:04:12PM +0200, Andreas K. Huettel wrote: |
| 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 |
>>> +1 |
| 9 |
>> Merge commits only happen if we allow non-fast-forward merges. I would |
| 10 |
>> personally be against allowing merge commits on the master branch. |
| 11 |
>> |
| 12 |
> Allowing fast-forward merges will break signature verification if you |
| 13 |
> fetched from a user repo. |
| 14 |
> If we don't allow merge commits, then _every_ commit hast to be signed |
| 15 |
> by a gentoo dev (e.g. by using git-am). I don't see much sense in this. |
| 16 |
> It will rather complicate workflow. |
| 17 |
> |
| 18 |
> The currently proposed verification script skips branch 'B', so what |
| 19 |
> matters is the signature of the merge commit which say "yes, I have |
| 20 |
> reviewed the users branch(es) and it's fine". |
| 21 |
> |
| 22 |
> Merging from branches holds useful information. A linear history isn't |
| 23 |
> necessarily easier to understand, so from me linear history gets a |
| 24 |
> |
| 25 |
> -1 |
| 26 |
> |
| 27 |
> It just isn't really "git" to me. But it also requires people to know |
| 28 |
> when to avoid merge commits. |
| 29 |
> |
| 30 |
>> Rebases involving commits that are already pushed to master probably |
| 31 |
>> shouldn't be allowed. |
| 32 |
>> |
| 33 |
> Of course, yes. That has to be documented in a gentoo developer git guide. |
| 34 |
Pretty please do NOT allow "merge" commits.. they are the bane of evil |
| 35 |
for the long term ability to have any sane work-flow. Trying browsing a |
| 36 |
commit history after a big merge commit.. or following the parent.. |
| 37 |
|
| 38 |
lastly - the "merge" commit itself could be very confusing to some |
| 39 |
people when viewed in github. (At least personally I find them |
| 40 |
frequently unreadable) |
| 41 |
|
| 42 |
After 5 years of git where I work - they are now banned (policy) and I |
| 43 |
wish github would allow them to be banned (non-fast forward) to avoid |
| 44 |
mistakes |
| 45 |
|
| 46 |
There's a big debate between merge vs rebase.. I'm not trying to go down |
| 47 |
the benefits of one workflow vs the other.. However, if rebase fails.. |
| 48 |
you can allow merge commits in the future.. The opposite isn't easily |
| 49 |
accomplished without squashing history and losing stuff.. |
Archives