I don't think there's much nuance in the "I don't know --first-parent exists" workflow. Yes, you may sometimes squash-merge a contribution coming from someone who can't use git well when you realize that it will just be simpler for everyone to do that than to demand them to clean their stuff up, but that's pretty much the only time you actually have a good reason to do that.

▲ l72 2 hours ago | parent | next [-]

I really, really wish git changed two defaults:

  * git merge ALWAYS does a merge and git pull ALWAYS does a fast forward.
  * git log --first-parent is the default. Have a git log --deep if you want to go down into branches.

If you use a workflow that always merges a PR with a merge commit, then git log --first-parent gives you a very nice linear history. I feel like if this was the default, so many arguments about squashing or rebasing workflows wouldn't be necessary to get our "linear history", everyone would just be doing merges and be happy with it. You get a clean top level history and you can dig down into the individual commits in a merge if you are bisecting for a bug.

▲ skydhash 6 hours ago | parent | prev [-]

Do people actually share PR as in different people contributing to the same branch?

Also I can understand not squashing if the contribution comes from outside the organization. But in that case, I would expect a cleaned up history. But if every contribution is from members of the team, who can merge their own PR, squash merge is an easy way to get a clean history. Especially when most PR should be a single commit.

▲

l72 2 hours ago | parent [-]

We do. If we are building out a feature, none of its code is merged into main until it is complete (if this is a big feature, we milestone into mergeable and releasable units).

The feature is represented by a Story in Jira and a feature branch for that story. Subtasks in jira are created and multiple developers can pick up the different subtasks. There is a personal branch per subtasks, and PRs are put up against the feature branch. Those subtasks are code reviewed, tested, and merged into the feature branch.

In the end, it is the feature branch that is merged (as a single merge commit and complete unit) into main, and may well have had contributions from multiple people.

	▲	skydhash an hour ago \| parent [-]
		I get your POV, but I’ve always considered that long-lived branches in the canonical repo (the one in the forge) other than the main one should be directly related to deployable artifacts. Anything else should be short-lived. There can be experiment on the side that warrants your approach, but the amounts of merge going back and forth would make this hard to investigate (especially when blaming) I would prefer to have one single commit with a message that describe every contribution.