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
