Re: git pull and merging.

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