Sure it looks nice, but it's a fake history. 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.
It's assuming that that merge conflicts will never be too difficult, and people won't make mistakes in resolving them. If so, too bad, the original commits are lost by the rebase process. (They might or might not be kept in any given clone. No guarantees, good luck trawling through the reflog.)
It's corrupting your database because it makes the UI for exploring it nicer.
This is the opposite of what we should be doing! If the truth is messy we should build better UIs for exploring it. Add additional information on top of the true history, allow people to group and describe commits. Add more information to get the UI that you want, rather than destroying information because it makes things look cluttered.
>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.
> 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.
CI will usually only run the latest commit. Even if commit a, b, and c were all tested, the resulting commits a', b', and c' after rebase would usually only have the last one tested.
> 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.
I take it that you've never reviewed a PR where the commits were a series of "wip" commits that don't even type check, much less pass the tests?
Undisciplined developers will be undisciplined. Forcing a rebase-free workflow mostly makes it less likely that these developers will lose work, it doesn't magically give you a clean commit history from them.
Nothing prevents people from committing untested code that doesn't even compile without any rebase involved. Even hooks don't help since the incompetent coworkers are just barely smart enough to learn about -n
It's assuming that that merge conflicts will never be too difficult, and people won't make mistakes in resolving them. If so, too bad, the original commits are lost by the rebase process. (They might or might not be kept in any given clone. No guarantees, good luck trawling through the reflog.)
It's corrupting your database because it makes the UI for exploring it nicer.
This is the opposite of what we should be doing! If the truth is messy we should build better UIs for exploring it. Add additional information on top of the true history, allow people to group and describe commits. Add more information to get the UI that you want, rather than destroying information because it makes things look cluttered.