>After a rebase you have commits where no one's ever run the tests, no author ever intended to get the repo into that state. Hell, most likely no one knows if the code even compiles.
Only true if the commit author doesn't do so, and it is trivial to do so, either during or after a rebase using the rebase exec command. So given this is a discipline issue no different from a developer authoring a change without testing it, I fail to see how this is "rebase"'s fault.
>it makes the UI for exploring it nicer
Not to imply I accept the "corrupt database" opinion, but I think it's worth saying that aside from the collaborative element of VCS, commits exist for the purpose of exploring past code changes. A practice which improves that seems sound to me.
I've never worked with a group that tested each of their rebased commits, and the rebase workflow definitely doesn't make that the default. It's possible, the options are there in the flow, but they're inconvenient and out of the way, and as a result, people don't use them in my experience.
> Not to imply I accept the "corrupt database" opinion, but I think it's worth saying that aside from the collaborative element of VCS, commits exist for the purpose of exploring past code changes. A practice which improves that seems sound to me.
I dispute that rebasing improves exploring history. It makes the history linear at the cost of making intermediate commits untrustworthy.
Both techniques require some manual discipline, and I'd feel differently if in practice people generally would lint and test each commit every time they rebased. If you do, then I've got no quarrel with ya.
> Only true if the commit author doesn't do so, and it is trivial to do so, either during or after a rebase using the rebase exec command. So given this is a discipline issue no different from a developer authoring a change without testing it, I fail to see how this is "rebase"'s fault.
"Undisciplined enough to use rebase, disciplined enough to put in extra effort to mitigate some of the harms of rebase" is an imaginary intersection.
This is begging the question (the fallacy, not the colloquial expression). It's only undisciplined to rebase if it's a bad practice, which is the topic under consideration here.
You can't use your preferred answer to the debate as justification for dismissing your opponent's arguments.
Only true if the commit author doesn't do so, and it is trivial to do so, either during or after a rebase using the rebase exec command. So given this is a discipline issue no different from a developer authoring a change without testing it, I fail to see how this is "rebase"'s fault.
>it makes the UI for exploring it nicer
Not to imply I accept the "corrupt database" opinion, but I think it's worth saying that aside from the collaborative element of VCS, commits exist for the purpose of exploring past code changes. A practice which improves that seems sound to me.
>we should build better UIs for exploring it
Go right ahead :)