Thanks for the clarification Francis. Using the git client it is possible to preserve the original author (even in the case of a squash merge) by setting the --author parameter during the commit.
Example: git commit --author="Stamatis Zampetakis <[email protected]>" I guess that's not possible with Github. Στις Παρ, 4 Ιαν 2019 στις 3:38 μ.μ., ο/η Michael Mior <[email protected]> έγραψε: > What we've done in the past is to add the original author's name in > parentheses to the commit message. Not ideal, but better than losing the > attribution entirely. I think it would be good to make an effort to ask the > contributor to do the squash themselves but in some cases, the PR is ready > to merge but the original contributor is no longer available. This > shouldn't hold us back. That said, I don't have a particular problem with > disabling the button on GitHub. > > -- > Michael Mior > [email protected] > > > Le ven. 4 janv. 2019 à 03:37, Francis Chuang <[email protected]> a > écrit : > > > Hey Stamatis, > > > > Squash merge on Github does preserve linear history. The commits are > > squashed into a new commit and then added to master. > > > > The problem with squash commit merge on Github is that the author of the > > squashed commit is set to the person who merged the PR and the committer > > is set to Github. > > > > This is not ideal, as the original author of the commits would not be > > given credit for their work. > > > > I think the best solution would be for PR authors to squash their > > commits locally and force push to their branch once work has been > > finalized. > > > > Francis > > > > On 4/01/2019 7:11 pm, Stamatis Zampetakis wrote: > > > Hi Francis, > > > > > > I had the impression that squash merge also retains the linear history. > > > I am always performing these operations using the git client; is the > > result > > > different when using Github? > > > > > > Best, > > > Stamatis > > > > > > Στις Πέμ, 3 Ιαν 2019 στις 11:37 μ.μ., ο/η Francis Chuang < > > > [email protected]> έγραψε: > > > > > >> Yesterday, Andrei brought to my attention that my attempt to merge > > >> Sergey's PR [1] using the default merge strategy (create a merge > commit) > > >> on Github broke the linear history of the calcite repository. > > >> > > >> I have since removed the commit and merged the PR using a rebase. > > >> > > >> I have also tested the merge behaviors on a test repo on Github. The > > >> "Rebase and merge" strategy will replicate what we are currently doing > > >> using the git client to preserve linear history. > > >> > > >> I have asked infra to disable the "create a merge commit" and "squash > > >> merge" strategies [2] on all our repositories. > > >> > > >> The merge button on Github should now be safe to use. In the event > that > > >> there is a conflict and Github is not able to perform the rebase, > > >> committers should manually rebase the commit(s) and merge the PR using > > >> the git client. > > >> > > >> [1] https://github.com/apache/calcite/pull/772 > > >> [2] https://issues.apache.org/jira/browse/INFRA-17541 > > >> > > > > > > > >
