Junio C Hamano <gitster@xxxxxxxxx> writes: > To understand why it is a wrong mental model, you need to imagine a world > where the logic to resolve conflicts in "git merge" is improved so that it > needs less help from the users. rerere.autoupdate is half-way there---the > user allows the merge machinery to take advantage of conflict resolutions > that the user has performed previously. Even though we currently do not > let "git merge" proceed to commit the result, it is entirely plausible to > go one step further and treat the resulting tree from applying the rerere > information as the result of the automerge. When that happens, it is very > natural for the user to expect that the rest of what "git merge" does for > a clean automerge to be carried out. After all, from the end user's point > of view, it _is_ a clean auto-merge. The only difference is how the user > helped the automerge machinery. Addendum. I am not suggesting that we should change rerere.autoupdate to go all the way and record a merge commit by default automatically when rerere applies cleanly. I personally think that it is a sensible default to set rerere.autoupdate to false (or not to set the variable at all) to ensure that a merge that conflicts is always inspected by the end user, given that rerere is merely a heuristic (even though it is a damn good one) and produces a surprising result. But that is a policy preference; some people want to trust rerere more than I do and that is a valid choice for them to make. To support such a policy preference, I am perfectly fine with introducing a third value to rerere.autoupdate in addition to yes/no to allow commands (e.g. "merge", "am", etc.) to continue when rerere resolved conflicts cleanly in a situation where they would have stopped and asked user to help resolving. 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'. Either the 'commit' command needs to detect that it is conclusing the merge and trigger the merge hooks the same way as 'merge' itself does, (which is a bad design, as 'commit' will need to know about the clean-up operations of all the other commands that may ask users to help and let 'commit' conclude it), or the end user instruction needs to be updated so that 'merge --continue' is used in such a situation to give 'merge' a chance to finish up. Again we could have "git continue" wrapper that knows how to tell what operation was in progress and invokes "merge --continue" when it detects that it was a 'merge' that was in progress, but that is a mere fluff. -- 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