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

[Ruslan Yakauleu <ruslan.yakauleu@gmail.com>]

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