Josef Weidendorfer <Josef.Weidendorfer@xxxxxx> writes: > More important: Because "branch.*.merge" specifies a _remote_ branch, > the user has to understand that this info is already used in the fetch. > The intuitive mental model of a user about how it works IMHO is that > "branch.*.merge" is checked in the merge phase (as the name of the option suggests). > But this way, how could the merge phase know about any remote branch at all, > which does not need to be touched at all in the merge phase? I accepted the "branch.*.merge" patch long time ago but I did not see the point of moving things into config back then, so I did not look at the design issue deeply enough to notice that this can be a source of confusion (in other words, "I wouldn't use it myself, but I've seen some people on the list wanting to have it, and the submitter must have thought about what are needed a lot more than myself" did not go so well). Once you place something like "branch.*.merge" in configuration file (either $GIT_DIR/config, or a $GIT_DIR/remotes/* file), you are talking about other repositories you regularly interact with, so it might be probably Ok to require the user to use a tracking branch if he wants the convenience of "branch.*.merge", and make its value name the local tracking branch instead of the remote branch. But that means I would never be able to benefit from the convenience of "branch.*.merge"; I pull from gitk repository to get updates, but I do not have (and I do not see the point to have) a remote tracking branch to track it. If you want to cater to people who fetch and merge without using tracking branches, the remote branch name is the only sane thing you can use for the value of "branch.*.merge". - 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