I don’t see how rebase frequency changes the problem of getting conflicts with some random commit within your long-lived branch, when doing a rebase.

I rebase often myself, but I don’t understand the logic here.

1) because git rerere remembers the resolutions to the ..

2) small conflicts when rebasing the long lived branch on the main branch

if instead I delayed any rebasing until the long lived branch was done, I'd have no idea of the scale of the conflicts, and the task could be very, very different.

Granted, in some cases there would be no or very few conflicts, and then both approaches (long-lived branch with or without rebases along the way) would be similar.

If you do a single rebase at the end, there is nothing to remember, you just get the same accumulated conflicts you also collectively get with frequent rebases. Hence I don’t understand the benefit of the latter in terms of avoiding conflicts.

You don't see a difference between dealing with conflicts within a few days of you doing the work that led to them (or someone else), and doing them all at once, perhaps months later?

This.

"If you do a single rebase at the end, there is nothing to remember, you just get the same accumulated conflicts you also collectively get with frequent rebases."

There is _everything_ to remember. You no longer have the context of what commits (on both sides) actually caused the conflicts, you just have the tip of your branch diffed against the tip of main.

"Hence I don’t understand the benefit of the latter in terms of avoiding conflicts."

You don't avoid conflicts, but you move them from the future to the present. If main is changing frequently, the conflicts are going be unavoidable. Why would you want to wait to resolve them all at once at the very end? When you could be resolving them as they happen, with all the context of the surrounding commits readily at hand. Letting the conflicts accumulate to be dealt with at the end with very little context just sounds terrifyingly inefficient.

If you rebase form main often, it keeps the difference to main quite small, so that when it comes time to do the final merge to main, it's either able to be fast-forwarded (keep it linear, good job!), or at least a very low risk of being conflicted (some people like merge commits, but at least your incoming branch will be linear). Because even though you might have commits that are a year old, initially branched from main from a year ago, their "base" has gradually become whatever main is _now_.

It's just like doing merges _from_ main during the lifetime of the branch. If you don't do any, you'll likely have lots of conflicts on the final merge. If you do it a lot, the final merge will go smooth, but your history will be pretzels all the way down.

In other words, frequent rebasing from main moves any conflicts from the future to "right now", but keeps the history nice and linear, on both sides!

Adding to your comment, I've found that frequent squashing of commits on the feature branch makes rebasing considerably easier - you only have to deal with conflicts on one commit.

And of course, making it easier to rebase makes it more likely I will do it frequently.