Normally pulling in changes from master is done by rebasing the branch on master, while putting in changes from a feature branch into master is a merge. This avoids making it seem the commits on master are part of your branch, and even avoids accidentally including something from master when your branch is merged but the change on master was reverted before that happened.

Is there a reason openjfx uses a merge to bring a branch up-to-date with master? As long as the commits on the branch are not squashed or altered it should not make reviewing any harder.

--John

On 15/08/2022 12:53, Jeanette Winzenburg wrote:

.. is something I _personally_ don't like: have to mentally sort the related from the unrelated commits in the history.

The contributing guidelines do allow intermediate merges (bolding by me)

"If you __need__ to pick up changes from master, you can merge master into your branch"

my interpretation would be: don't without good reason.

To merge or not to merge, that is the quesion :)

-- Jeanette

Reply via email to