This is a poor and incorrect analogy for rebase. Someone using rebase is conducting the reconciliation and then rewriting their commit to account for it, while simplifying the commit history and hiding it.<p>When a commit lands in master, it doesn&#x27;t matter to anyone else how it was developed. Those events are almost outside the &quot;light cone&quot;. Those who rebase a commit onto the upstream branch recognize that the little details of how it was made have no relevance to others and thus do not belong in shared history.<p>People often speak about preserving history while missing the point that source history is most meaningfully logical, not physical. Imagine an editor that made a new commit for every key press. That would be a true recounting of history, and yet would be irrelevant. Most feature development can and should land as one commit; the details of how it was made are, like the key presses that composed it, minimally relevant to anyone but the author.