What is a non-merge commit?

Question

In the announcement of Linux 5.15-rc1 Linus said:

At only just over 10k non-merge commits, this is in fact the smallest rc1 we have had in the 5.x series.

What is a non-merge commit? What's the opposite of a non-merge commit?

Answer 1

If you're working in a feature branch, that branch might have a significant lifespan. By that I mean that the originating branch (master or develop usually) receives many commits while the feature branch is off on its own. This could be because the feature is unexpectedly delayed, was expected to take a long time, or if there's lot of concurrent development happening (e.g. large dev teams). For whatever reason, the situation I'm focusing on is one where a lot of things happen to master between the start and end of your specific feature branch.

Eventually, the feature branch needs to merge back into master. However, if master has significantly changed since then, there may be conflicts because the feature was written against an outdated codebase which is no longer the same as today's master code.

It is generally considered to be better to have multiple small issues instead of one big one at the end.

To avoid having such a big break event, it is advised to regularly merge master back into your feature branch. This means that you introduce the new changes that have been made to master in your feature branch, so that you can quickly spot and fix any conflicts that may arise.

Those merges from master into the feature branch, when they are not rebase actions, generate a commit message to the feature branch history. Something along the lines of:

2021-01-01   Started feature branch
2021-01-01   Added FOO
2021-01-02   Merged from master
2021-01-02   Refactored FOO
2021-01-02   Added BAR
2021-01-03   Merged from master
2021-01-04   Merged from master
2021-01-05   Added BAZ

But really, those merge commits don't indicate how much work has happened on this branch. They only indicate how much changes have occurred on other branches during the lifespan of this branch. In reality, there have been 4 commits on this feature branch that are indicative of work that has happened on this feature.

Therefore, if you're trying to express the amount of work that went into a specific branch, you should measure the commits except merge commits, since they are not a measure of development on the actual branch.

Hence why Linus is expressing the amount of non-merge commits to indicate the relative size of rc1.

Answer 2

In git each commit is a specific version of the code, and it includes information about which previous version(s) it was based on - those commits are known as its parents.

A merge commit is a commit that has two or more parents, i.e. it is bringing together multiple lines of development. Usually it is bringing a line of development of a feature into the main general line of development of the entire product. It doesn't normally include any original development work other than bringing things together.

A non-merge commit is a commit with less than two parents. (Normally exactly one parent). The majority of commits in a project are usually non-merge commits, where a programmer has done some work on top of one specific previous version.

Answer 3

A "non-merge" commit is a commit that introduces an actual code change. A merge commit just moves around changes that were already introduced by non-merge commits.

That's why non-merge commits can be a measure of productivity or change, assuming every commit introduces, on average, a similar "amount" of change.