Hacker News Reader

Comment by rictic | Hacker News Reader

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.

View on HN

>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 :)

> 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

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.

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.

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

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.

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

So rebase then force push a', wait for CI, push b', wait for CI, push c'? Personally I just squash on merge.

And if you care about each commit always passing all test you should change your CI config accordingly.

> 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

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

Reply on news.ycombinator.com