Changing git merge behavior in release 1.7.10

In accordance with the release calendar, there are only a few weeks left until the list of features for the next release of git (1.7.10) is frozen, which will include improvements in git merge, violating backward compatibility and compromising those who use merge in their scripts.
We decided to follow the advice of Jake Edge: “Most of the free projects discuss the planned changes before they are implemented and give users the opportunity to test new features long before the release. The best assistance to the project at this stage is clearly substantiated, specific descriptions of existing problems, missing functionality, etc., and not an endless stream of “Project XYZ SLEEP !!! 11” messages in mailing lists or comments ”

Therefore, I will describe the decision we made, why it was made, and how users of the next release can use it in their work.


When git merge tries to merge two or more branches, a description is generated - which branches participated in the merge and, if the automatic merge is successful, this stub is recorded as a description of the commit without any intervention from the user. If the automatic merge fails, we give the user a chance to fix everything on their own and use git commit to record the result.
')
Most mergers take place without any problems, and it is this behavior that has led people to do a merge without thinking, even in those situations when it is necessary to explain the reason for this action. No one bothers to call git commit --amend to fill in a description of the reasons for a merge after a successful merge.

Recently, on the Git mailing list, Linus noticed (and I agree with him) that this behavior is a system design error made at the very dawn of Git. And now, starting from 1.7.10, when you run git merge in the console (standard input and output are connected to the terminal), an editor opens to create a description of the commit, giving the user a chance to explain the reasons for his action.

We would like to give a couple of recommendations that can help our users get used to this change:

(1) When git merge is started from the command line, two options are possible:
- you are adding the updated upstream to the branch in which you are working on a new functionality (topic branch). Such a merger with no real reason is a bad practice. Such a merging in the “wrong” direction should be done only when absolutely necessary, for example, if your new functionality depends on improvements recently adopted in upstream. Otherwise, your branch ceases to contain commits related to the same unit of functionality, and, instead, becomes a dump of commits from different sources. In this case, the new git merge behavior is in your hands, because will no longer have to call a amendment to find out the reasons.
- when a branch with a new functionality is injected into an integration branch (or a testing branch), the reason for the merger is usually clear from the context - you are pouring the finished functionality into a project. In this case, you can pass the --no-edit parameter to the git-merge call and accept the prepared message without editing

(2) You have a script that executes git merge and you left the standard input and output stream attached to the terminal, the script will ask the user about the reasons for the merge. This may not be desirable. For example, often such scripts are used to mass merge a large number of branches into a test branch and should remain non-interactive as long as such automatic merging is possible. Obviously, in this case, you want to keep the old behavior of the team. It is not necessary to add --no-edit to every git merge call. Instead, you can define the environment variable MERGE_AUTOEDIT = no at the beginning of your script and git merge will silently commit until the first conflict

Try 1.7.10 before release and adapt your scripts and habits :)
If you have wishes regarding:
- documentation
- errors, recommendations and other messages
- interactive start definition logic
We are always happy to hear from you on the git@vger.kernel.org mailing list.

The very fact of launching the editor with an interactive merge is not discussed. As Linus said - the default matters - and how the merge behaved before was a really bad “silence”

Bring this news to Git users in your environment so that they can begin to change their habits.