Hacker News Reader

Comment by cube00 | Hacker News Reader

It depends on that context, if they're the end of day "work in progress" or "typo" commits, I don't see the value in retaining those.

A non-linear commit history is much more difficult to run a bisect on which was enough to sell linear for me.

View on HN

The bisect might be easier to do, but it's vastly less useful if you're looking for why and not what since the commits are not actually the authors originals and the state of the project you find is not the state the author authored them within.

For us only the original authors squash and tidy up their own commits so they can add as much context as they want.

That's not to say each PR is one commit, if there are multiple distinct parts of a PR that could be cherry picked in a way that they make sense on their own they'd still be separate commits.

> That's not to say each PR is one commit

This thread is about squash merge, which converts the whole branch into a single commit.

`git bisect --first-parent` is just as easy as a bisect on linear history. (It just follows the "linear" line down merge commits via their first parent, which by convention should be their "base" parent.) Plus it gives you the option to bisect "inside" a branch if you need to inspect something "low level" once you've narrowed down the "branch" based on merge commit. I think if `--first-parent` were the default to git bisect a lot more people would care a lot less about "linear commit history". But it is still an easy flag to apply yourself.

typo commits might be really useful, especially if you can bisect a bug from one of those commits. it happened to me.

Reply on news.ycombinator.com