[Mithaldu]

Looking at the recent history i can see how you'd come to like it. You seem to mostly be doing merges or documentation changes, which probably means you don't have to do a lot of history spelunking to fix bugs caused months ago.

Are you sure your developers feel the same as you do? Are you sure they're willing to be open enough to you about their misgivings?

[sytse]

I think the majority of people on our team don't like rebasing because it makes spelunking harder in some cases. But there are certainly people that preferred having some commits rebased so it was easier to revert them (reverting a merge is possible but harder). Although I'm not an active developer myself I think my dislike of rebasing everything is shared.

[Mithaldu]

> I think the majority of people on our team don't like rebasing because it makes spelunking harder in some cases.

Would you elaborate on that please? I don't know what your situation is like that would cause rebasing to make spelunking harder.

> reverting a merge is possible but harder

Funny, someone else further down claimed reverting merges is easier. :)

[sytse]

Because you rewrote history it is harder to see what was written, tested by hand and tested with CI at what time.

[Mithaldu]

Another social issue. In the projects i work with, it is commonly agreed upon and known that of course after a rebase every commit needs to be retested and reverified with CI. It is a bit of extra work, but as i mentioned in another commit: We do that extra bit of work now, to avoid having to analyze the cross-talk of a bunch of branch merges at a later point; mainly because that bit of later work often turns out to be considerably bigger. (Technical debt is a talking point here.)

Of course, this might be unviable when under unusual time pressures.