[masklinn]

It’s important to note that not all history is worth keeping, and keeping a dozen commits titled “fix” fixing build / CI errors from the original changes are a lot worse for bisecting than squashing it all into just one.

I very much prefer keeping histories by default (both my personal workflows and the tools I build default to that) but squash is a valuable tool.

[lmm]

> keeping a dozen commits titled “fix” fixing build / CI errors from the original changes are a lot worse for bisecting than squashing it all into just one.

How so? When I bisect I want to get down to a small diff, landing on a stretch of several commits (because some didn't build) is still better than landing on a big squashed commit that includes all those changes and more. The absolute worst case when you keep the original history is the same as the default case when you squash.

[masklinn]

Because they’re broken and their only purpose is to fix up the original change, so it’s functionally the same change.

> The absolute worst case when you keep the original history is the same as the default case when you squash.

No, now you have a bunch of worthless broken commits that you need to evaluate and skip because they’re not the problem you’re looking for.

[lmm]

> Because they’re broken and their only purpose is to fix up the original change, so it’s functionally the same change.

Do you restrict yourself to 1 non-broken commit per PR? I don't, and nor does anyone I've worked with. If there were even 2 non-broken commits in the PR, then bisecting with the original history lands you on a diff half the size that bisecting with squashed history would, which is a significant win. (If you didn't care about that sort of thing you wouldn't be bisecting at all).

> No, now you have a bunch of worthless broken commits that you need to evaluate and skip because they’re not the problem you’re looking for.

What are you "evaluating"? If you want to ignore the individual commits and just look at the overall diff that's easy. If you want to ignore the individual messages and just look at the PR-time message that's easy too. Better to have the extra details and not need them than need them and not have them.

[masklinn]

> Do you restrict yourself to 1 non-broken commit per PR?

No. To the extent that I can however I do restrict myself to only non-broken commits.

> If there were even 2 non-broken commits in the PR, then bisecting with the original history lands you on a diff half the size that bisecting with squashed history would, which is a significant win

It is not a significant win when the bisecting session keeps landing me in your broken commits that I have to waste time evaluating and skipping.

And splitting out fixups doesn’t save anything (let alone “half the size”), most commonly those fixups are just modifying content the previous commits were touching already, so you’re increasing the total diff size you have to evaluate.

> What are you "evaluating"?

Whether the commit is the one that caused the issue I’m bisecting for.

> If you want to ignore the individual commits and just look at the overall diff that's easy. If you want to ignore the individual messages and just look at the PR-time message that's easy too.

Neither of these is true. git bisect (run) lands me on a commit, it’s broken, now I need to look whether the commit is broken in a way that is relevant to what I’m seeking.

> Better to have the extra details and not need them than need them and not have them.

Garbage is “extra details” only in the hoarder sense.

[lmm]

> It is not a significant win when the bisecting session keeps landing me in your broken commits that I have to waste time evaluating and skipping.

Skipping a commit that doesn't build is trivial (especially if you're automating your bisects).

> And splitting out fixups doesn’t save anything (let alone “half the size”), most commonly those fixups are just modifying content the previous commits were touching already, so you’re increasing the total diff size you have to evaluate.

If you feel the need to rebase to squash one-liner fixups into the commits they fix then that's a more subtle tradeoff and there are reasonable arguments. But squashing your whole PR for the sake of that is massive overkill, and the costs outweigh the benefits.

[masklinn]

> Skipping a commit that doesn't build is trivial (especially if you're automating your bisects).

A broken commit usually compiles, if you don’t even compile before committing you should go back to school.

> If you feel the need to rebase to squash one-liner fixups into the commits they fix then that's a more subtle tradeoff and there are reasonable arguments. But squashing your whole PR for the sake of that

It would really have helped if you’d stated upfront that you can’t read.