Re: [PATCH] merge: --ff-one-only to apply FF if commit is one

Hi Junio,

Command of developers can decide which policy use and why. If a team decides to avoid extra merges - why not?

 > a single commit could be a large and involved
Create one non-reviewable commit or losing feature scope is much worse
practice

For me `git log --graph` is the most representative form to describe what's going on with a project and I prefer not to complicate it. But it must show changes properly.

--ff-one-only is handy for keeping the appearance of a linear commit history and makes merge commit messages (from other branches) more meaningful because they actually do represent some branch being folded into the master.

As an example, merge commit for one commit is overkill and doesn't bring new meaning. All one-commit meanings described in the commit message. In this case extra branching (extra merges) just adds confusion. Plenty of extra merges turns into merge hell when you have countless merge messages, but you can't get sense what's going on with project.

People use rebase and fast-forward to make commit history more linear, avoid merge hell and keep the repository tree clear - it's fine. But it's a big mistake to merge complex features as one non-reviewable commit. And even worse to make all history absolutely linear when you can't find where a complex feature starts and where it finishes. If it wasn't combined in a special branch, it looks in the main branch like a set of different, not connected features. In the case of problems with absolutely linear history, you don't know how many commits you have to revert. In case when one commit (merge commit for complex features) brings all changes into the main branch - you know that you can revert feature or, for complex changes, even part of a specific feature. You can revert just A/B tests for example, if you don't need them anymore but keep complex features - this case makes squash even more useless. You can try to use branch names to find where each branch merged into the main branch, but it's not as descriptive as a graph and every so often you can lose branch names. As an example, GitLab has an option "Delete source branch when merge request accepted" and many teams use it.

-- Ruslan