Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html