[cweagans]

> it makes history a lie that eventually collapses under its own weight in large teams

Can you please elaborate on this? I've seen this argument from others as well, but nobody has ever been able to articulate what that actually looks like and why rebasing branches specifically is to blame.

My perspective: whatever happens to the commit history on your non-`main` branch is your business. I don't care about the specifics until your work is merged into a shared branch that we all understand to be the canonical representation of the software we're working on.

[idoubtit]

I'm not the GP, but I've seen "rebase lies" in the wild.

Suppose a file contains a list of unique strings, one by line. A commit on a feature branch adds an element to the list. Later on, the branch is rebased on the main branch and pushed.

But the main branch had added the same element at another position in the list. Since there was a wide gap between the two positions, there was no conflict in Git's rebase. So the commit in the feature branch breaks the unicity constraint of the list.

For someone that pulled the feature branch, the commit seems stupid. But initial commit was fine, and the final (rebased) commit is a lie: nobody created a duplicate item.

[cweagans]

Thanks for that. I'm definitely familiar with that kind of situation, but what I'm not seeing is how that leads to history "collapsing under its own weight" in larger teams. That seems like a relatively straightforward rebase error that is easily corrected. (Also, if it is important for that list to only include unique items and you were able to merge it anyway, maybe that also reveals a gap in the test suite?)

[cxr]

> Can you please elaborate on this?

You're replying to an LLM-powered comment generator.