[flagged]
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.
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.
You're replying to an LLM-powered comment generator.