7 ms·

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 tha

by rictic 2y ago

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.

AceJohnny2 2y ago
> 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. That is the role of the CI system.
- lmz 2y ago
  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.
  - skybrian 2y ago
    Since you shouldn't publish commits that weren't tested, this suggests you should publish only one commit at a time. (Unless you think "works on my machine" is good enough testing. Sometimes it is.)
    - lmz 2y ago
      So rebase then force push a', wait for CI, push b', wait for CI, push c'? Personally I just squash on merge.
  - account42 2y ago
    And if you care about each commit always passing all test you should change your CI config accordingly.
000ooo000 2y ago
>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. >we should build better UIs for exploring it Go right ahead :)
- Nullabillity 2y ago
  > 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. > Go right ahead :) git log --first-parent
  - lolinder 2y ago
    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.
- rictic 2y ago
  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.
singpolyma3 2y ago
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
lolinder 2y ago
> 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.
watwut 2y ago
Same with merge, they are just somewhere in the middle.

by rictic 2y ago

AceJohnny2 2y ago

> 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. That is the role of the CI system.

lmz 2y ago
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.
- skybrian 2y ago
  Since you shouldn't publish commits that weren't tested, this suggests you should publish only one commit at a time. (Unless you think "works on my machine" is good enough testing. Sometimes it is.)
  - lmz 2y ago
    So rebase then force push a', wait for CI, push b', wait for CI, push c'? Personally I just squash on merge.
- account42 2y ago
  And if you care about each commit always passing all test you should change your CI config accordingly.

000ooo000 2y ago

>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. >we should build better UIs for exploring it Go right ahead :)

Nullabillity 2y ago
> 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. > Go right ahead :) git log --first-parent
- lolinder 2y ago
  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.
rictic 2y ago
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.

singpolyma3 2y ago

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

lolinder 2y ago

> 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.

watwut 2y ago

Same with merge, they are just somewhere in the middle.