Summary: every feature is merged with 'main' as the first parent. Then, whenever interacting with history, you tell git you only want it to consider --first-parent
The problem is getting all the visualization tools on the same page.
Bazaar got this right. Their official UI displays a linear history with the ability to expand any merge commit to show the side branch.
https://commons.wikimedia.org/wiki/File:Bazaar_Explorer_-_Lo...
But I can see why people might still desire more explicit constructs to handle history organization. The expectation that the commit graph should be both logical and historical causes a sort of cognitive dissonance, which these sorts of conventions don't fully resolve.
They're a commit with two parents, one of which has no real meaning anymore because it doesn't exist anywhere else. They break a lot of tools because of this.
The second parent is the last commit of a series of commits starting at a commit, sometime in the past on the main branch, followed by all the new commits that represent the feature that is being merged.
Merges are horrible, if you don't have a mental model of git that aligns exactly to the above.
What do you mean? That's the feature branch, what's the issue?
l = log --graph --abbrev-commit --date=relative
And he's right. If someone does the merge while checked out on the feature branch, then commits it _as_ the master branch, then the first-parent concept breaks.
Don’t do it for the same reason that you have a convention of useful commit messages.
Which makes it nearly useless. Not totally - the people who know about it benefit - but it's extremely far from safe. The only way to really enforce this is to add this kind of thing to your "main" remote repo that everyone pushes to.
e.g. Add new feature foo to main menu
...