streamline github dev process

[Mojca Miklavec]

On 1 June 2017 at 03:43, Helmut K. C. Tessarek wrote:
> On 2017-05-31 20:42, Joshua Root wrote:
>> That's an unavoidable side effect of rebasing (or squashing) -- it's no
>> longer the same commit that you signed.
> Right, this is why one usually does a merge with --no-ff. Thus my commit
> is intact and the merge commiter gets their own commit. Problem solved.
>
> There's no reason for doing it any other way.
>
> Why do a rebase for a PR? Especially in this project it's highly
> unlikely that there will be a conflict. But even if there were, the same
> conflict would have happened with a rebase.

I see no reason for not having a linear history other than perhaps
signatures (and complexity of work). But then there are far more cases
when some trivial modifications of PRs are needed and the majority of
contributors didn't set up signatures anyway. (With Trac/SVN there was
even no attribution.)

Maybe we could review our guidelines in the future, but at the moment
it looks nicer to me to avoid a zillion of merge commits.

Mojca