Unless we live in some parallel universe, everything is linear...
I think you simply miss the idea of linearizability...
I think you simply miss the idea of linearizability...
It follows then that if a merge commit is a genuine reconciliation, then a rebase is the act of one party rewriting their own memory in order to hide from themselves the fact that they were working in isolation and later had to agree on the actual outcome of events. Thus, in effect, rebasing ones code is no different than suffering from a self-inflicted delusion. That is, a delusion that we are all working in one shared directory or, to a lesser extent, that there is one source of truth as in SVN or other centralised systems.
This is, in fact, quite a sad thing our community. Many a developer -- while they may be using git -- are not truly using git in the way it was intended. They have limited themselves to their old ways of thinking and acting and, in the pursuit of what they have been taught is "the ideal", they have hidden from themselves the possibilities, efficiencies and understanding that might be discovered by the move into a world which can capture the fact that not everyone works in a single shared directory with immediate knowledge of each other's work.
We have to learn to embrace the oddity of a non-linear history because, while we might not like it, it represents what really happens when we write code. The better our tools help us model reality the better answers we can produce for ourselves now and in the future. Six months from now when we say, "How the hell did this ever work?" or "What the fuck was I thinking when I wrote that?", we'll want answers. If we choose rebase, corrupt our own memories and burn the reflogs we'll never know.
When a commit lands in master, it doesn't matter to anyone else how it was developed. Those events are almost outside the "light cone". 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.
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.
Since the purpose of a revision history is to enable historians to gather a complete picture of a feature's genesis so as to interpret the author's changes and mental states prompting those changes in their correct context all of recorded history should facilitate that purpose. If rebase workflows do indeed encourage big atomic commits which drop features into a repository as though they were commandments from a god then obviously they do not help historians understand the authorial intent that went into their creation. You yourself argue for just that as do, in my observations, most users of rebase oriented workflows. Additionally, the heart of rebase workflows themselves, namely retroactively changing the parent of a commit, misrepresents what the author knew at the time that code was written. This clearly misleads the historian and I find the workflow to be dishonest and unhelpful in preserving the very reason we use revision control and thus I judge it harmful.
If one uses rebase (say, in interactive squash mode) to clean up and regroup commits into small logical chunks in order to facilitate the understanding of authorial intent then I don't have any issues with it at all. It's when it is used to misrepresent, overload and mislead the historian for the sake of a "good looking" git log that I find the usage of rebase distasteful.
An author should never be so self-absorbed that they believe that no-one but themselves could possibly care how they did their work and arrived at the conclusion they did. Authors that abuse their tools really have no excuse and best remember that they themselves are also historians with respect to other people's code and, in time, their own.
On the contrary — this is one of the most important pieces of information I hope to get from my VCS.