Hacker News Reader

Comment by donatj | Hacker News Reader

> I still believe that a squash+merge (or sometimes, rebase) workflow pairs better with pull requests

Unpopular opinion, but I find the value of having the actual surrounding context in which the code was developed more valuable than having a flat history.

View on HN

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.

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.

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

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

> I find the value of having the actual surrounding context in which the code was developed more valuable

But only if those commits are real atomic changes of code which compiles and not a series of 'oops', 'tests pass once again!' , 'forgot to commit this file' type inner-monologue type history.

And then there are shops where less technical authors are contributing solely via the GitHub WebUI. So you get a commits of the ilk 'Updated <Filename>' or ''Files added via upload'.

I'm not sure this is too unpopular. In our groups not rebasing seems to be winning.

Reply on news.ycombinator.com