Jakub Narebski <jnareb@xxxxxxxxx> writes: > 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. I agree that trusting merge blindly is bad, but still, if there are no merge conflicts, and if the merge is broken, I'd prefer commiting a fixup patch right after the merge than fixing it before committing. Because if the merge needs a fix, it usually means something tricky that deserves its own patch and commit message. At worse, one can still reset --merge HEAD^. One other issue with not committing automatically is for beginners. I see that all the time when the merge has conflicts. newbies fix the conflicts, and when they're done: "fine, conflicts solved, let's continue hacking" without committing. The resulting history is totally messy because it mixes merges and actual edits. For these users, not committing automatically in the absence of conflict would make the situation even worse. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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