[BobbyTables2]

For code reviews that take days/weeks, it is useful to not rebase the branch to main/master on every update… But I certainly see no point in merging it in when it based on an ancient ancestor…

I’ve heard some like the non-fast-forward approach because it preserves the historical state of the tree when a developer was writing something… Often the same people who don’t squash commits and merge 100 commit branches where 99 are a complete mess.

But to me, what matters is the actual change to main/master at the time the thing is merged — that is what affects the team.

If some people want to keep unsquashed, unrebased branches for archival purposes? Fine! But rebase before merging to main/master!

[baptou12]

  But to me, what matters is the actual change to main/master at the time the thing is merged — that is what affects the team.

Totally agree, if the developper goes in wrong product direction at the beginning and add 10 additional commits afterwards: team + 6 month actually don't care about it.

  I certainly see no point in merging it in when it based on an ancient ancestor

If you want the CI to run, before the merge on the result it will produce on main branch ?