Junio C Hamano <gitster@xxxxxxxxx> writes: > By the way, on the other side of this same coin lies another use case > (different from the one in the footnote in the previous message) for > "merge --no-commit". When you know that a particular merge _will_ need > semantic adjustments, even if it were to textually merge cleanly, you > would want the command to ask you for help to come up with the final tree, > instead of trusting the clean automerge result. This often happens when > the topic branch you are about to merge has changed the semantics of an > existing function (e.g. adding a new parameter) while the branch you are > on has added new callsite to the function (or the other way around). In > such a merge, you would need to adjust the new callsite that does not know > about the additional parameter to the new function signature. For exactly > the same reason, it is not a kosher advice to give to users of modern Git > to "interfere with the merge with 'merge --no-commit', and then conclude > with 'commit'", as 'commit' has less information than 'merge' itself what > 'merge' wants to do in addition to recording the result as a 'commit'. Yet another issue is if we should blindly trust automatic merge resolution. It is considered a good practice by some to always check (e.g. by compiling and possibly also running tests) the result of merge, whether it required merge conflict resolution or not. IIRC Linus lately said that making "git merge" automatically commit was one of bad design decisions of git, for the above reason... -- Jakub Narębski -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html