[skydhash]

The upsides are great. PRs should be atomic, introducing changes as a set. I don’t care about the history of the branch, I only care that the changes in the PR are one unit that can be reverted as a whole. And each commit in the main branch passes the tests.

[keybored]

I get those so-called upsides with `git log --first-parent`. I can view the changes as one set of changes or all of the individual ones.

But I can’t relate in general to those workflows where PRs have to be tiny and revertable (why need to revert so often).

[skydhash]

It’s mostly about project management. In a project, the unit is a task. These tasks will then have discussion around then and then get assigned to the people that are going to do the implementation. After the latter is done and approved, it will be deployed and the task will be marked as done.

Having your git history reflecting this is great when you need to take decisions. Because no one will care about your individual commits. Every discussion will revolve about the task. So you make the PRs a bijective relation with it, and by extension the commits on the main branch. Then for special group of tasks like features, you have a specific branch you manage the same way. The other branches you create PRs from can be as messy as you like. And your local copy is yours to do whatever you want.

[keybored]

I know what project management and tasks are.

Commits are in practice a superset of all of that. Some commits will correspond to a task. But many commits will just do the work without having to go through the beaurocracy of “project management”. Having to “project manage” each and every commit if you want a useful and fine-grained (but not micromanaged) version control history is impractical.

There’s a lot of small tasks in the concrete code. It doesn’t make sense to give every little change a task.

And the flipside of that is that you can give up on making commits that are fine-grained enough. Now you’re back in squash town where, sure, your task list is just right. But your commits are sometimes a jumble of different concerns in order to stick to one-task-on-commit.

> Because no one will care about your individual commits.

Will someone care about your tasks?

You don’t pre-empt what commits you care about when you are trying to find the reason for some change in the Git history. You don’t find the exact commit that explains it, clear as day, and then throw it away because there is no associated task.

> So you make the PRs a bijective relation with it, and by extension the commits on the main branch.

It sounds useful with a mathematical name I guess?

Insisting on one-to-one mappings for such small things like commits smells of micromanagement. Yes, either people-management or your own time management.

[skydhash]

> Having to “project manage” each and every commit if you want a useful and fine-grained (but not micromanaged) version control history is impractical.

You're misunderstand me there. I'm talking about the main branch's commits, on the main repository, not every branch and every commits, and not the local repos. And it's not dogmatic, just very nice to have. If you want a hotfix, it's very easy to create a new branch, commit the fix, push it, create a PR, and squash merge it. Unless you like to edit "main" directly on a collaborative project.

Or you can then instruct everyone how to cleanup their commits and make sure that each one is atomic. And you can merge your usual way. I have no dog in this fight. It's just that the above is easier to do. It's pretty much the same result.

[keybored]

> You're misunderstand me there. I'm talking about the main branch's commits, on the main repository, not every branch and every commits, and not the local repos.

No I don’t. I’m also talking about the commits that go into the main branch. The “permanent history”, not all the commits that happen on feature branches.

> And it's not dogmatic, just very nice to have.

A squash-only policy is by definition dogmatic. That’s the only thing that I’ve argued against here—a policy. Having the freedom to do it or not is totally different.

> Or you can then instruct everyone how to cleanup their commits and make sure that each one is atomic. And you can merge your usual way. I have no dog in this fight. It's just that the above is easier to do. It's pretty much the same result.

No. OR you can let people do what they want. Let them squash if they want.

If squashing is such a win they can do that. No instructions necessary.

[skydhash]

I do agree with you in principle and it’s nice when professionals come together and the work experience is fluid. No need for policy.

But that rarely happens and you need these kind of safeguards and directive for the team to be productive at all. It especially avoid discussions about who’s right.