Josef Weidendorfer wrote: > Now looking at it, I think this semantic really is screwed and utterly confusing. > Why decides branch.*.merge about actions done in fetch (I think even if you did > "git fetch" alone)? OK, actually, that is an implementation detail and not > really important. > > 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? > > IMHO we should somehow change the semantic of branch.*.merge to specify the _local_ > refspec part, as this is the branch which actually gets merged. > This is the only way that a user could grasp the meaning of it. > Perhaps introduce "branch.*.defaultmerge", and obsoleting "branch.*.merge"? The change of semantic would prohibit the "pull without tracking branch" semantic (probably not used anymore, since git supports multiple heads from long time). I proposed in another thread to allow to either specify full refspec (in addition to current specifying remote branch), or ':' and local branch. Or perhaps add branch.*.localmerge configuration option? -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - 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