Hi Andreas, Andreas Enge <andr...@enge.fr> writes:
> Am Sat, Aug 09, 2025 at 01:31:46PM +0900 schrieb Maxim Cournoyer: >> and there was also mention by Leo F. of problematic auto-conflict >> resolution in merge commits > > In that sense, rebasing is a bit easier since merge conflicts are resolved > one after the other, instead of all together at the moment of merging. > I think with the core-packages-team branch, for instance, that would have > been a major endeavour, since the branch was so long-lived. Rebasing made > it possible to adapt over a few months to a changing master branch. Ah yes, that's a good advantage of using rebase, for when syncing with master is necessary/wanted, for long lived branches. It also avoids cluttering the history. > And if we continue to rebase branches, then the "merge" would simply be > a fast-forward, no? Except if in the end we rebase a little bit behind > the tip of the master branch (even one commit behind HEAD), then the merge > would be visible. At least this is how I imagine things... Feature/topic branches should continue being rebased yes, it's just as you wrote when doing the final integration with master that we'd use a 'git merge'. -- Thanks, Maxim
