If your workflow or VCS doesn't allow rebase natively then people will implement it in the filesystem by never committing.
Git's approach to committing is: "commit early, commit often". The coro;lary is: "don't worry about perfection, we can fix it later". Such flexibility to me is very enabling and allows for a lot of very beneficial experimentation in the process of developing features.
Honestly, I don't understand your fascination with the sausage-making. If I were to give you the pre-rebase and post-rebase version of patches I would wager you would find much more value in the latter. And if not. Even if seeing the wandering, hacking, slashing, typoing, re-indenting, etc. is instructive to you, any future maintainer of the code will be far less pleased.
Git's approach to committing is: "commit early, commit often". The coro;lary is: "don't worry about perfection, we can fix it later". Such flexibility to me is very enabling and allows for a lot of very beneficial experimentation in the process of developing features.
Honestly, I don't understand your fascination with the sausage-making. If I were to give you the pre-rebase and post-rebase version of patches I would wager you would find much more value in the latter. And if not. Even if seeing the wandering, hacking, slashing, typoing, re-indenting, etc. is instructive to you, any future maintainer of the code will be far less pleased.