Should I include necessary additional changes in a merge commit?

Question

I'm going to explain my question with a concrete example where this question has cropped up:

I'm working on a large-ish Django project with a few people. Django automatically creates migration plans and saves them to separate files when the database model is changed. Edits to the model may be applied on different branches in parallel. Django actually supports this with the introduction of merge migrations.

In essence, after merging branches with diverging changes to the model, you create another migration plan which references all the leaves in the graph of migration plans (comparable to the way Git represents merges).

Now my question is this: On the grounds that after merging branches without adding the merge migration, the project is not broken per se (an existing setup continues to run), but its also not in a very good state either (you can't apply migrations to a database or initialize a new one), should I include the merge migration in the merge commit itself or should I add it in a separate commit? What are the implication of doing it in one or the other way?

My question is about the general case where a merge introduces inconsistencies, not by breaking the code itself (i.e. renaming a method where another usage has been introduced in the other branch), but on a higher level, which could include inconsistent documentation or broken auxiliary data (test data and scripts, installation scripts, default settings files).

• Demian Brecht: Have you looked at manually resolving the merge conflicts in the migration files? i.e. having one person with the latest version of the code delete the conflicting migration files and re-run makemigrations? You shouldn't have to deal with merge scenarios at all in that case.
• Feuermurmel: @DemianBrecht Thats an interesting approach. That would probably be the appropriate course of action when the feature branch was rebased. The problem is that developers already have applied the migrations on their branches to some development environments. Re-creating the migrations would require the migrations in those environments to be rolled back and re-applied.

Answer 1

For me, it depends if I can get it right in one try or not. If making the additional changes to get the code correct after a merge can be done and tested on the first try, and I am confident in that, I consider that part of the merge commit and will include it. That means I run all the tests before I complete my merges.

On the other hand, if the changes are something I might have to experiment with several times, then it's beneficial to have a checkpoint in version control to go back to, especially if I need to coordinate with a teammate. This situation is relatively rare compared to the first one, though.