Josef Weidendorfer wrote:

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