Hacker News Reader

Comment by seba_dos1 | Hacker News Reader

> In the rare case you do actually care what PR a commit is from, GitHub's search will tell you.[1]. There's no need to put that information in a commit at all.

Even better - if you work with linear history (like most GitHub projects do I guess), you can always require merges to be fast-forwardable, but create a merge commit anyway. This way you retain all the individual commits and they're being grouped together by pull requests, so you can easily filter the details out with flags like `--first-parent` when you're not interested in them.

Squashing PRs truly is absolutely useless.

View on HN

The tooling just isn't there, though, especially if you want to do something like signing. I want to have my whole merge/pull request history in one subtree, while having the 1st subtree maintain a clear linear history with MR/PR Numbers in each merge commit, and also have that one be signed by the committer. It's easy to represent. It's a little harder to get the forges to do it right.

> Squashing PRs truly is absolutely useless

That is quite an absolute statement. Some people just have a personal preference for having git trees arranged in a certain way. If squashing can help with that, then it serves a purpose.

Squashing is an essential tool for everyday git use. Squashing pull requests wholesale at merge time as the default merging strategy? It only hurts. It's a clear case of using the wrong tool only because you haven't learned a better one yet. Maybe it is "quite an absolute statement" - but I have never seen a valid justification for its use.

Have you ever worked at a company where every engineer has in depth knowledge of git?

In my experience 90% of software engineers get as far as pull, push, commit, maybe merge. Rebase and amend if you're very lucky

Squash merges make git easier to use for 90% of engineers and therefore unless you have significantly above average git knowledge in your company it makes sense as a default strategy

Coming from a completely different culture where the word 'engineer' still means something, I find this quite funny. If your 'engineers' just smash keys together until it seems to work somehow (which includes never bothering to learn the full potential of DVCS — one of our most important tools), they're not really engineers IMHO. Real ones know their tools (I don't pretend to be one and never call myself that).

That's not in-depth knowledge, that's basic usage. I don't have in-depth knowledge of git myself, most of its plumbing is an opaque black box for me. Less obvious but useful things like `--first-parent` are just one manpage reading session away. If your colleagues are unable to perform some basic rebases to squash away their WIP commits, you may want to help them learn how to use one of the most essential tools in their work. Everyone in your team will benefit.

Reply on news.ycombinator.com