I too would rather avoid complicated graphs in my git histories. However, I see value in the merge commits as they very clearly show the "two brains" principle, and retain context for sets of commits.
Here is a sample for the Standard for Public Code:
In the above, it can easily be seen that for each contribution one person created a change and another person reviewed and merged it.
Also the logical grouping of sets of commits are retained, as in the case of the 3 roadmap related commits by Ainali.
While not perfectly linear (as long as there is a rebase before merge) the commit history remains easy to understand and remains linear from a git bisect perspective.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I too would rather avoid complicated graphs in my git histories. However, I see value in the merge commits as they very clearly show the "two brains" principle, and retain context for sets of commits.
Here is a sample for the Standard for Public Code:
In the above, it can easily be seen that for each contribution one person created a change and another person reviewed and merged it.
Also the logical grouping of sets of commits are retained, as in the case of the 3 roadmap related commits by Ainali.
While not perfectly linear (as long as there is a rebase before merge) the commit history remains easy to understand and remains linear from a
git bisectperspective.