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
