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